Affinity non "regola l'utilizzo della CPU" (ad esempio, nel caso in cui le CPU eseguano meno lavoro), consente di spegnere una CPU (forse per renderla disponibile a un'altra istanza sulla stessa macchina) o impostare una CPU su aiuto solo con I / O. Anche se avessi più CPU, non saresti in grado di utilizzare il primo per aiutarti con il tuo obiettivo, ed è impossibile per noi indovinare il secondo perché non sappiamo cosa sta guidando l'utilizzo della tua CPU così in alto. Potrebbe essere dovuto a indicizzazione estremamente scadente, compilazioni eccessive, abbondanza di UDF scalari, thrashing I / O, chi lo sa? (E la ragione per cui l'I / O potrebbe essere la causa è che se il tuo database è più grande di circa 3 GB, dovrà costantemente scambiare dati dentro e fuori dalla memoria del pool di buffer, e questo avrà un impatto sulla CPU.)
La cache della CPU, inoltre, è una tana di coniglio che non è necessario scendere. Dubito fortemente che la tua CPU stia crollando al 95% a causa di problemi con la cache della CPU.
Per limitare la fonte della pressione della CPU e supponendo che tu stia utilizzando le procedure memorizzate, puoi dare un'occhiata a questa query diagnostica da Glenn Berry ( proveniente da qui ) - assicurati di eseguirla nel contesto del database giusto:
-- 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
Se non si utilizzano procedure memorizzate, questo esempio di John Samson può aiutare a isolare le query ad hoc ( provenienti da qui ):
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);
Puoi anche dare un'occhiata a sp_WhoIsActive di Adam Machanic , una procedura memorizzata che può analizzare rapidamente tutte le query attualmente in esecuzione e consentirti di ordinarle come preferisci (ad esempio nel tuo caso @sort_order = '[CPU] DESC').
La prima cosa che farei, anche se in particolare se questo è veramente fondamentale per le squadre di ricerca e salvataggio, è acquistare hardware migliore. Dovresti avere più CPU e più RAM per servire la tua applicazione. È inoltre assolutamente necessaria una migliore disponibilità elevata (ad esempio clustering, mirroring o gruppi di disponibilità). Non vi è alcun motivo per cui un riavvio di una macchina fisica debba portare la tua applicazione completamente offline - abbiamo soluzioni migliori per questo problema. E infine, presumo che questo "server" abbia solo un disco rigido. Ciò significa che tutto l'I / O - dal sistema operativo, dai file di dati di SQL Server, dai file di registro, dal tempdb, ecc., Passa attraverso un singolo controller e condivide l'attività di lettura / scrittura su una singola unità. Ottieni più dischi. Ottieni SSD se / dove puoi. Utilizzare RAID e provare a distribuire l'I / O il più possibile.
Detto questo, lanciare l'hardware al problema non sarà l'unica parte della correzione. È necessario isolare esattamente cosa sta causando un uso eccessivo della CPU e quindi attaccare tali problemi, indipendentemente dall'hardware in uso.
Vedi anche questa domanda StackOverflow per alcune altre idee:
/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server