Коли вносити зміни до порогу витрат на паралелізм

При розгляді проблеми продуктивності, я бачив приплив на CXPACKETS припускаючи , я , можливо , потрібно подивитися на поріг витрат на паралелізм і , можливо, MAXDOP.

Перш ніж вносити будь-які різкі зміни в MAXDOP, я дотримуюся порад багатьох інших людей, включаючи @mrdenny у відповіді на CXPACKET Чекає налаштування продуктивності для SQL Server 2008 та відповідь @ aron-Bertrand від " Справа з CXPACKET" чекає - встановлення порогової вартості за паралелізм . Я додав до обслуговування, щоб оновлювати статистику щомісяця. Це відчувається як розумний хід.

Однак внесення змін до межі вартості все одно мене знущає.

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

Вибачте, якщо це щось, на що відповіли в попередньому запитанні.

Дякую!

Використання MAXDOP = 1 може допомогти, але це велика зброя. Можливо, актуальною проблемою є корисність індексів. Можливо, новий чи інший індекс вирішить проблему.

Після коментарів містера Денні та Аарона Бертран, ви виявили, які інші очікування у зв'язку з цим, ймовірно, стали причиною очікування CXPACKET?

Джонатан Кехайас запропонував запит, який може допомогти вам оцінити ваш паралелізм та прийняти більш продумане рішення. Але ви також повинні прочитати розмову між Джонатаном та Полом Вайт.

https://www.sqlskills.com/blogs/jonathan/tuning-cost-threshold-for-parallelism-from-the-plan-cache/

Я б запропонував вам спершу вивчити налаштування MAXDOP, оскільки налаштування за замовчуванням 0 (використовуйте всі доступні потоки) може бути небезпечним, оскільки запит, що споживає всі наявні потоки, призведе до голодування ниток.

Дивіться моя відповідь тут для того, як обчислити параметр MAXDOP для екземпляра сервера.

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

Зауважте, що очікування CXPACKET - це лише симптоми через те, що щось не так пов’язано із запитом - застаріла статистика або відсутній індекс, що призводить до поганого чи іншого плану.

Ви можете використовувати sys.dm_exec_cached_plansта sys.dm_exec_query_planDMV для видобутку інформації з кешу плану, як описано в « Настроювання порогу витрат на паралелізм» з кешу плану Джонатана та Порогової вартості для паралелізму .

Я б запропонував зберегти за cost threshold for parallelismзамовчуванням, якщо ви не вичерпали ресурси, налаштовуючи запити, виконуючи обслуговування індексів і статистики, а також перевірили, чи немає у вас відсутніх індексів, що ваш запит може отримати користь.

Примітка. Налаштування Maxdop також можна застосувати на рівні запиту, використовуючи OPTION (MAXDOP n)який буде замінено налаштування на сервері.