Назад | Перейти на главную страницу

Высокий тип ожидания CXPACKET в SQL Server даже с MAXDOP = 1

У меня всегда был очень высокий тип ожидания CXPACKET, и мне сказали, что он проистекает из параллельной обработки, и я должен сохранить МАКСИМАЛЬНУЮ СТЕПЕНЬ ПАРАЛЛЕЛИЗМА = (Nº Processors / 4), или 1 в моем случае.

Но ожидания CXPACKET по-прежнему очень высоки - 32,78% от всех ожиданий. Какие-либо предложения?

Тип ожидания CXPACKET, скорее всего, не является причиной вашей проблемы, а скорее ее следствием.

Этот тип ожидания означает, что рабочий ожидает завершения какой-либо другой операции, прежде чем она сможет продолжить. Вы должны проверить сеанс, отвечающий за CXPACKET, и посмотреть, чего именно он ждет:

SELECT session_id, wait_type, wait_time, start_time, *
FROM SYS.dm_exec_requests
WHERE session_id > 50
GO

SELECT * 
FROM sys.dm_os_waiting_tasks AS t
WHERE session_id > 50
GO

Только после того, как вы диагностируете настоящую причину проблемы, вы можете предпринять действия, чтобы попытаться ее смягчить.

На самом деле это не означает, что существует проблема ... параллелизм - это хорошо, и тип ожидания CXPacket отображается только потому, что SQL Server должен синхронизировать различные части работы.

Когда вы переключаетесь на maxdop = 1, время выполнения этого фрагмента кода медленнее, чем при параллельном выполнении? Это, так сказать, настоящая проба пудинга.

Есть много противоречащих друг другу статей, но эти две написаны SQL-специалистами, которые знают, о чем они говорят! (хорошо, один из них перешел на сторону Oracle!)

http://itknowledgeexchange.techtarget.com/sql-server/cxpacket-isnt-the-cause-it-is-a-symptom/

http://sqlserverpedia.com/blog/sql-server-bloggers/cxpacket-maxdop-and-your-oltp-system/

Вы очищали статистику ожидания после того, как снизили максимальную степень параллелизма до 1?

Но на самом деле нет действительного простого универсального практического правила о том, как следует настраивать этот параметр, кроме измерения воздействия любых вносимых вами изменений. В дополнение к указанным выше URL-адресам я бы рекомендовал прочитать этот сообщение Пола Рэндала.

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

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

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


Из того, что я видел на практике, высокий процент ожиданий CXPACKET указывает на большое параллельное сканирование таблиц.

Используйте SQL Profiler для анализа запросов, выполняемых в экземпляре: велика вероятность, что их нужно настроить по индексу или, возможно, даже переписать, чтобы они были более эффективными. Ожидания CXPACKET - это просто симптом (возможной) проблемы.