Affinity не "коригує використання процесора" (наприклад, у вашому випадку змушує CPU виконувати менше роботи), вона дозволяє або вимкнути ЦП (можливо, зробити його доступним для іншого екземпляра на тій же машині) або встановити ЦП на допомога лише вводу / виводу. Навіть якби у вас було декілька процесорів, ви не змогли б використати перший для того, щоб допомогти з вашою метою, і ми не можемо здогадатися про останню, тому що ми не знаємо, що сприяє використанню вашого процесора настільки високо. Це може бути через надзвичайно погану індексацію, надмірну компіляцію, велику кількість скалярних АДС, обмітання вводу / виводу, хто знає? (І причиною того, що введення-виведення може бути причиною, є те, що якщо ваша база даних перевищує 3 Гб або більше, їй постійно доведеться обмінюватися даними з пам’яті пулу буферної пам’яті і вимикати дані, і це сприймає свою плату на процесорі.)
Кеш процесора - це також кроляча діра, яку вам не потрібно знижувати. Я дуже сумніваюся, що ваш процесор обмотаний на 95% через проблеми з кешем процесора.
Щоб зменшити джерело тиску ЦП та припускаючи, що ви використовуєте збережені процедури, ви можете ознайомитися з цим діагностичним запитом від Глена Беррі ( джерело звідси ) - переконайтеся, що ви запускаєте його в контексті потрібної бази даних:
-- 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
Якщо ви не використовуєте збережені процедури, то цей приклад від Джона Самсона може допомогти виділити спеціальні запити ( отримані звідси ):
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);
Ви також можете поглянути на sp_WhoIsActive Адама Маханіка , що зберігається процедура, яка може швидко проаналізувати всі поточні запити, що дозволяють, і дозволити їх сортувати як завгодно (наприклад, у вашому випадку @sort_order = '[CPU] DESC').
Перше, що я би зробив, особливо - якщо це дійсно важливо для місій пошуково-рятувальних груп - це придбати краще обладнання. Ви повинні мати більше процесорів та більше оперативної пам’яті, щоб обслуговувати свою програму. Також вам абсолютно потрібна краща висока доступність (наприклад, кластеризація, дзеркальне відображення або групи доступності). Немає причин, що перезавантаження фізичної машини повинно брати вашу програму повністю в автономному режимі - у нас є кращі рішення для цієї проблеми. І нарешті, я припускаю, що цей "сервер" має лише один накопичувач. Це означає, що всі введення-виведення - з ОС, з файлів даних SQL Server, файлів журналів, tempdb тощо, всі проходять через один контролер і діляться активністю читання / запису на одному диску. Отримайте більше дисків. Отримайте SSD, якщо / де можете. Використовуйте RAID і намагайтеся максимально поширити введення-виведення.
Все, що сказано, кидання обладнання на вирішення проблеми не буде єдиною частиною виправлення. Вам потрібно виділити саме те, що викликає надмірне використання процесора, а потім атакувати ці проблеми, незалежно від того, на якому апаратному забезпеченні ви працюєте.
Також дивіться це питання StackOverflow щодо деяких інших ідей:
/programming/945063/how-do-i-find-out-what-is-hammering-my-sql-server