Как мне узнать, что мешает моему SQL-серверу?

StackOverflow https://stackoverflow.com/questions/945063

Вопрос

Большую часть сегодняшнего дня мой процессор SQL Server работал примерно на 90%.

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

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

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

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

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

Мне нужен любой способ выяснить, что вызывает сбой процессора в SQL.

Это было полезно?

Решение

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

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

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

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

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

Другие советы

Этот запрос использует 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 по процессору

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

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

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

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

Выполните любое из этих действий с интервалом в несколько секунд.Вы обнаружите высокое подключение к процессору.Или:сохраненный процессор в локальной переменной, ОЖИДАНИЕ ЗАДЕРЖКИ, сравнение сохраненных и текущих значений процессора

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

select * from master..sysprocesses
order by CPU
desc

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

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

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

Расследование причины высокого уровня процессора 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

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

Лицензировано под: CC-BY-SA с атрибуция
Не связан с StackOverflow
scroll top