Affinity no "ajusta el uso de la CPU" (por ejemplo, en su caso hace que las CPU realicen menos trabajo), le permite apagar una CPU (quizás para que esté disponible para otra instancia en la misma máquina) o configurar una CPU para ayuda solo con E / S. Incluso si tuviera múltiples CPU, no podría usar la primera para ayudarlo con su objetivo, y es imposible para nosotros adivinar la segunda porque no sabemos qué está impulsando el uso de su CPU tan alto. Podría deberse a una indexación extremadamente pobre, recopilaciones excesivas, abundancia de UDF escalares, sacudidas de E / S, ¿quién sabe? (Y la razón por la que la E / S podría ser la causa es que si su base de datos es más grande que 3 GB, tendrá que intercambiar datos constantemente dentro y fuera de la memoria de la agrupación de almacenamiento intermedio, y esto afecta a la CPU).
El caché de la CPU, también, es un agujero de conejo que no necesita estar cayendo. Dudo mucho que su CPU tenga un rendimiento del 95% debido a problemas con el caché de su CPU.
Para ayudar a reducir la fuente de presión de la CPU, y suponiendo que esté utilizando procedimientos almacenados, puede consultar esta consulta de diagnóstico de Glenn Berry ( obtenida de aquí ): asegúrese de ejecutarla en el contexto de la base de datos correcta:
-- 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
Si no está utilizando procedimientos almacenados, este ejemplo de John Samson puede ayudar a aislar consultas ad hoc ( obtenidas de aquí ):
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);
También puede echar un vistazo a sp_WhoIsActive de Adam Machanic , un procedimiento almacenado que puede analizar rápidamente todas las consultas que se ejecutan actualmente y le permite ordenarlo como desee (por ejemplo, en su caso @sort_order = '[CPU] DESC').
Sin embargo, lo primero que haría, especialmente si esto es realmente una misión crítica para los equipos de búsqueda y rescate, es comprar un mejor hardware. Debería tener más CPU y más RAM para dar servicio a su aplicación. También necesita una mejor alta disponibilidad (por ejemplo, agrupación en clúster, duplicación o grupos de disponibilidad). No hay razón para que el reinicio de una máquina física deje su aplicación completamente fuera de línea; tenemos mejores soluciones para ese problema. Y finalmente, supongo que este "servidor" solo tiene una unidad de disco espinosa. Esto significa que todas las E / S, desde el sistema operativo, los archivos de datos de SQL Server, los archivos de registro, tempdb, etc., pasan por un solo controlador y comparten la actividad de lectura / escritura en una sola unidad. Consigue más discos. Obtenga SSD si / donde pueda. Use RAID e intente extender la E / S lo más posible.
Dicho todo esto, lanzar hardware al problema no será la única parte de la solución. Debe aislar exactamente qué está causando el uso excesivo de la CPU y luego atacar esos problemas sin importar en qué hardware se encuentre.
Consulte también esta pregunta de StackOverflow para conocer otras ideas:
/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server