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

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

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

Источник

4 ответа

Решение

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

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

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

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

Источник

Тип ожидания 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/

Источник

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

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

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

Источник
Другие вопросы по тегам