У меня возникли проблемы с производительностью системы обработки данных, над которой я работаю. Я собрал статистику ожидания за один час, который показывает большое количество событий ожидания CXPACKET и LATCH_EX.
Система состоит из 3 обрабатывающих SQL-серверов, которые выполняют много вычислений и вычислений, а затем подают данные на центральный кластерный сервер. Серверы обработки могут иметь до 6 запущенных заданий одновременно. Эти статистические данные о ожидании относятся к центральному кластеру, который, я думаю, вызывает узкие места. Центральный кластерный сервер имеет 16 ядер и 64 ГБ оперативной памяти. MAXDOP установлен в 0.
Я предполагаю, что CXPACKET является результатом выполнения нескольких параллельных запросов, однако я не уверен, что указывает событие ожидания LATCH_EX. Из того, что я прочитал, это может быть без буфера ожидания?
Кто-нибудь может подсказать, какова будет причина такого рода статистики ожиданий и какие действия я должен предпринять, чтобы выяснить причину этой проблемы с производительностью?
Верхние результаты запроса - это общая статистика ожидания, а нижние результаты запроса - статистика за 1 час.
Ответы:
CXPACKET может сопровождаться LATCH_XX (возможно, также с PAGEIOLATCH_XX или SOS_SCHEDULER_YIELD). Если это так (и я полагаю, что это основано на вопросе), то значение MAXDOP должно быть уменьшено, чтобы соответствовать вашему оборудованию.
Помимо этого, вот еще несколько рекомендуемых шагов по диагностике причины высоких значений статистики CXPACKET wait (перед изменением чего-либо на SQL Server):
Не устанавливайте MAXDOP в 1, поскольку это никогда не является решением
Изучите запрос и историю CXPACKET, чтобы понять и определить, произошло ли это что-то один или два раза, поскольку это может быть просто исключением в системе, которая обычно работает правильно
Проверьте индексы и статистику по таблицам, используемым запросом, и убедитесь, что они актуальны
Проверьте порог стоимости для параллелизма (CTFP) и убедитесь, что используемое значение подходит для вашей системы
Проверьте, сопровождается ли CXPACKET LCK_M_XX (обычно сопровождается IO_COMPLETION и ASYNC_IO_COMPLETION). Если это так, то параллелизм не является узким местом. Устраните эти статистические данные ожидания, чтобы найти основную причину проблемы и решения
Если вам действительно нужно глубоко понять тип ожидания CXPACKET, я бы посоветовал прочитать статью Устранение неполадок с типом ожидания CXPACKET в статье SQL Server.
источник
Прочтите раздел Диагностика и устранение конфликтов защелок на SQL Server , это самая полная статья по этой теме. Вам нужно будет покопаться
sys.dm_os_latch_statsи посмотреть, какой тип защелки имеет место.Посмотрите, поможет ли вам каким-либо образом чтение Как анализировать производительность SQL Server .
источник
В дополнение к чтению приведенных выше ссылок и, скорее всего, к изменению значения параметра «Максимальная степень параллелизма» с 0 на что-то вроде 8, вы захотите сузить, какие из ваших запросов идут параллельно и какова их стоимость.
Увидев влияние этого изменения, вы также можете рассмотреть возможность изменения «порогового значения стоимости для параллелизма» для точной настройки того, что будет идти параллельно.
Вот отличное видео от Брента Озара, которое поможет вам: Овладение искусством CXPACKET и MAXDOP
Ваша цель - <= 50% времени ожидания CXPACKET. Удачи!!
источник