Powinowactwo nie „dostosowuje użycia procesora” (np. W twoim przypadku powoduje, że procesory wykonują mniej pracy), pozwala albo wyłączyć procesor (być może udostępnić go innej instancji na tym samym komputerze), albo ustawić procesor na pomoc tylko z I / O. Nawet jeśli miałeś wiele procesorów, nie byłbyś w stanie użyć tego pierwszego do pomocy w osiągnięciu celu, a nie możemy zgadywać na drugim, ponieważ nie wiemy, co powoduje tak wysokie użycie procesora. Może to być spowodowane bardzo słabym indeksowaniem, nadmiernymi kompilacjami, dużą ilością skalarnych UDF, przebijaniem We / Wy, kto wie? (A powodem, dla którego operacje wejścia / wyjścia mogą być przyczyną, jest to, że jeśli baza danych jest większa niż około 3 GB, będzie musiała stale wymieniać dane z pamięci puli buforów i z niej wyrzucać, a to odbije się na procesorze.)
Pamięć podręczna procesora to również królicza nora, której nie musisz schodzić. Wątpię, czy Twój procesor bije w 95% z powodu problemów z pamięcią podręczną procesora.
Aby pomóc zawęzić źródło obciążenia procesora i zakładając, że korzystasz z procedur przechowywanych, możesz rzucić okiem na to zapytanie diagnostyczne od Glenna Berry'ego ( tutaj ) - upewnij się, że uruchamiasz je w kontekście odpowiedniej bazy danych:
-- Top Cached SPs By Total Worker time (SQL Server 2012).
-- Worker time relates to CPU cost (Query 44) (SP Worker Time)
SELECT TOP (25)
p.name AS [SP Name],
qs.total_worker_time AS [TotalWorkerTime],
qs.total_worker_time/qs.execution_count AS [AvgWorkerTime],
qs.execution_count,
ISNULL(qs.execution_count/DATEDIFF(Second, qs.cached_time, GETDATE()), 0)
AS [Calls/Second],
qs.total_elapsed_time,
qs.total_elapsed_time/qs.execution_count AS [avg_elapsed_time],
qs.cached_time
FROM sys.procedures AS p WITH (NOLOCK)
INNER JOIN sys.dm_exec_procedure_stats AS qs WITH (NOLOCK)
ON p.[object_id] = qs.[object_id]
WHERE qs.database_id = DB_ID()
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);
-- This helps you find the most expensive cached stored procedures from a CPU perspective
-- You should look at this if you see signs of CPU pressure
Jeśli nie korzystasz z procedur przechowywanych, ten przykład od Johna Samsona może pomóc w wyodrębnieniu zapytań ad hoc ( pochodzących stąd ):
SELECT TOP (25)
qs.sql_handle,
qs.execution_count,
qs.total_worker_time AS Total_CPU,
total_CPU_inSeconds = --Converted from microseconds
qs.total_worker_time/1000000,
average_CPU_inSeconds = --Converted from microseconds
(qs.total_worker_time/1000000) / qs.execution_count,
qs.total_elapsed_time,
total_elapsed_time_inSeconds = --Converted from microseconds
qs.total_elapsed_time/1000000,
st.text,
qp.query_plan
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
CROSS apply sys.dm_exec_query_plan (qs.plan_handle) AS qp
ORDER BY qs.total_worker_time DESC OPTION (RECOMPILE);
Możesz także rzucić okiem na sp_WhoIsActive Adama Machanica , procedurę składowaną, która może szybko analizować wszystkie aktualnie uruchomione zapytania i umożliwiać sortowanie ich w dowolny sposób (np. W twoim przypadku @sort_order = '[CPU] DESC').
Pierwszą rzeczą, którą bym zrobił, zwłaszcza jeśli jest to naprawdę kluczowe dla zespołów poszukiwawczych i ratowniczych, jest zakup lepszego sprzętu. Powinieneś mieć więcej procesorów i więcej pamięci RAM do obsługi aplikacji. Absolutnie potrzebujesz też lepszej wysokiej dostępności (np. Klastrowania, kopii lustrzanej lub grup dostępności). Nie ma powodu, dla którego ponowne uruchomienie komputera fizycznego powinno całkowicie wyłączyć aplikację - mamy lepsze rozwiązania tego problemu. I wreszcie zakładam, że ten „serwer” ma tylko jeden dysk twardy. Oznacza to, że wszystkie operacje wejścia / wyjścia z systemu operacyjnego, z plików danych programu SQL Server, plików dziennika, tempdb itp. Przechodzą przez jeden kontroler i współużytkują operacje odczytu / zapisu na jednym dysku. Zdobądź więcej dysków. Zdobądź dyski SSD, jeśli / gdzie możesz. Użyj RAID i staraj się jak najbardziej rozpowszechnić We / Wy.
To powiedziawszy, rzucanie sprzętem na problem nie będzie jedyną częścią poprawki. Musisz dokładnie wyodrębnić, co powoduje nadmierne użycie procesora, a następnie zaatakować te problemy bez względu na sprzęt.
Zobacz także pytanie StackOverflow, aby uzyskać inne pomysły:
/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server