Чекає високий CXPACKET і LATCH_EX

У мене виникають деякі проблеми з продуктивністю із системою обробки даних, над якою я працюю. Я зібрав статистику очікування від годинної пероїди, яка показує велику кількість подій очікування CXPACKET та LATCH_EX.

Система складається з 3-х серверів обробки SQL, які здійснюють багато обчислень та обчислень чисел, а потім подають дані на центральний сервер кластерів. На серверах обробки може бути до 6 завдань, що працюють у будь-який час. Ця статистика очікування призначена для центрального кластеру, який, на мою думку, спричиняє вузькі місця. Сервер центрального кластера має 16 ядер і 64 ГБ оперативної пам’яті. MAXDOP встановлено на 0.

Я думаю, що CXPACKET походить із кількох паралельних запитів, проте я не впевнений, що вказує подія очікування LATCH_EX. З того, що я прочитав, це може бути небуферне очікування?

Чи хтось може підказати, яка причина такої статистики очікувань та який напрямок дій мені слід вжити, щоб дослідити першопричину цієї проблеми?

Основними результатами запиту є загальна статистика очікування, а нижній результат запиту - статистика за 1 годину

CXPACKET може супроводжуватися LATCH_XX (можливо, також PAGEIOLATCH_XX або SOS_SCHEDULER_YIELD). Якщо це так (і я вважаю, це так, виходячи з питання), то значення MAXDOP слід знизити, щоб відповідати вашому обладнання.

Окрім цього, ось ще кілька рекомендованих кроків для діагностики причини високих значень статистики очікування CXPACKET (перш ніж щось змінити на 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, ви хочете звузити, які з ваших запитів паралельно і яка їх вартість.

Побачивши вплив цієї зміни, ви також можете розглянути можливість зміни "Порогової вартості для паралелізму", щоб точно налаштувати те, що буде йти паралельно.

Ось чудове відео від Brent Ozar, яке допоможе вам: Оволодіння мистецтвом CXPACKET та MAXDOP

Ваша мета - <= 50% відсотка часу очікування для CXPACKET. Щасти!!