Как я узнаю, что бьет мой SQL Server?

Question

Большая часть моего ЦП на SQL Server была на уровне 90% на сегодняшний день.

Я не в состоянии перезапустить его из-за его постоянного использования.

Можно ли выяснить, что в SQL вызывает такую ​​перегрузку процессора?

Я запустил SQL Profiler, но так много всего происходит, что трудно сказать, вызывает ли это что-то конкретное.

Я запустил sp_who2, но не уверен, что все это значит точно и возможно ли здесь определить возможные проблемы.

Чтобы предупредить любые ответы «возможно, это просто много», это только сегодня с совершенно нормальных уровней активности.

Я пытаюсь найти причину горячих ЦП в SQL.

Answer 1

В этом запросе используются DMV для определения наиболее дорогостоящих запросов по процессору

SELECT TOP 20
    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

Полное объяснение см .: Как определить самые дорогостоящие запросы SQL Server по ЦП

Answer 2

Я полагаю, что при должной осмотрительности вы подтвердили, что ЦП фактически потребляется процессом SQL (счетчики категории процессов perfmon подтвердили бы это). Обычно для таких случаев вы берете выборку соответствующих счетчиков производительности и сравниваете их с базовым уровнем, который вы установили в условиях нормальной нагрузки. После того, как вы решите эту проблему, я рекомендую вам установить такой базовый уровень для будущих сравнений.

Вы можете точно определить, где SQL тратит каждый цикл ЦП. Но зная, где искать, нужно много знать, как и опыт. Это SQL 2005/2008 или 2000? К счастью для 2005 года и новее, есть несколько готовых решений. У вас уже есть пара хороших указателей здесь с ответом Джона Самсона. Я хотел бы добавить рекомендацию для загрузки и установки отчетов панели мониторинга производительности SQL Server . Некоторые из этих отчетов включают самые популярные запросы по времени или по операциям ввода-вывода, наиболее часто используемые файлы данных и т. Д., И вы можете быстро понять, в чем проблема. Вывод является как числовым, так и графическим, поэтому он более полезен для начинающих.

Я бы также порекомендовал использовать скрипт Адама "Кто активен" , хотя он немного более продвинутый.

И, наконец, что не менее важно, я рекомендую вам скачать и прочитать технический документ MS SQL Customer Advisory Team по анализу производительности: Ожидания и очереди SQL 2005 .

Я также рекомендую посмотреть на ввод-вывод. Если вы добавили нагрузку на сервер, который очищает пул буферов (т. Е. Ему нужно столько данных, что он вытесняет страницы с кэшированными данными из памяти), результатом будет значительное увеличение ЦП (звучит удивительно, но это правда). Виновником обычно является новый запрос, который сканирует большую таблицу целиком.

Answer 3

Вы можете запустить SQL Profiler и фильтровать его по процессору или длительности, чтобы исключить все «мелочи». Тогда вам будет намного проще определить, есть ли у вас проблема, такая как определенный хранимый процесс, который выполняется намного дольше, чем должен (это может быть отсутствующий индекс или что-то в этом роде).

Два предостережения:

• Если проблема в огромном количестве крошечных транзакций, то фильтр, который я описал выше, исключит их, и вы пропустите это.
• Кроме того, если проблема заключается в одиночной, масштабной работе (например, 8-часовом аналитическом задании или плохо спроектированном выборе, который должен перекрестно соединить миллиард строк), то вы можете не увидеть это в профилировщике, пока оно не будет полностью сделано, в зависимости от того, какие события вы профилируете (sp: завершено против sp: заявление завершено).

Но обычно я начинаю с монитора активности или sp_who2.

Answer 4

Запустите любой из этих нескольких секунд. Вы обнаружите высокую загрузку процессора. Или: сохраненный CPU в локальной переменной, WAITFOR DELAY, сравнение сохраненных и текущих значений CPU

select * from master..sysprocesses
where status = 'runnable' --comment this out
order by CPU
desc

select * from master..sysprocesses
order by CPU
desc

Может быть, не самый элегантный, но эффективный и быстрый.

Answer 5

Для подхода с графическим интерфейсом я бы взглянул на Activity Monitor в разделе «Управление» и отсортировал по процессору.

Answer 6

Вы можете найти полезный запрос здесь:

Исследование причины высокой загрузки ЦП SQL Server

Для меня это очень помогло:

SELECT s.session_id,
    r.status,
    r.blocking_session_id 'Blk by',
    r.wait_type,
    wait_resource,
    r.wait_time / (1000 * 60) 'Wait M',
    r.cpu_time,
    r.logical_reads,
    r.reads,
    r.writes,
    r.total_elapsed_time / (1000 * 60) 'Elaps M',
    Substring(st.TEXT,(r.statement_start_offset / 2) + 1,
    ((CASE r.statement_end_offset
WHEN -1
THEN Datalength(st.TEXT)
ELSE r.statement_end_offset
END - r.statement_start_offset) / 2) + 1) AS statement_text,
    Coalesce(Quotename(Db_name(st.dbid)) + N'.' + Quotename(Object_schema_name(st.objectid, st.dbid)) + N'.' +
    Quotename(Object_name(st.objectid, st.dbid)), '') AS command_text,
    r.command,
    s.login_name,
    s.host_name,
    s.program_name,
    s.last_request_end_time,
    s.login_time,
    r.open_transaction_count
FROM sys.dm_exec_sessions AS s
    JOIN sys.dm_exec_requests AS r
ON r.session_id = s.session_id
    CROSS APPLY sys.Dm_exec_sql_text(r.sql_handle) AS st
WHERE r.session_id != @@SPID
ORDER BY r.cpu_time desc

В полях статуса, wait_type и cpu_time вы можете найти наиболее ресурсоемкую задачу, которая выполняется сейчас.