Потрібно зрозуміти помилку виконання паралельного запиту

Сьогодні ми відчули погіршення продуктивності на нашому сервері виробництва sql. Протягом цього часу ми зафіксували кілька "The query processor could not start the necessary thread resources for parallel query execution"помилок. Прочитання, яке я зробив, говорить про те, що це стосується того, скільки процесорів слід використовувати під час виконання складного запиту. Однак коли я перевірив під час відключення наш CPU Utilization was only at 7%. Чи є ще щось, на що могло б посилатися, що я ще не натрапив? Це вірогідний винуватець погіршення продуктивності чи я переслідую червону оселедець?

Мої значення sp_configure для цього такі:

name                                minimum maximum config_value run_value
cost threshold for parallelism      0       32767   5            5

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

Як зазначав Рем, це називається голодування робочих ниток .

Коли ця умова відбудеться, на вашому сервері буде створено дамп пам'яті.

Якщо ви перебуваєте на 2008R2 + SP1 і вище, тоді sys.dm_server_memory_dumpsви також отримаєте дамп-файл.

Тепер повернемося до проблеми:

На 1 вузол NUMA є 1 потік монітора планування, і оскільки у вас є 2 NUMA-вузла, будуть 2 монітора монітора планувальника, які відповідають за перевірку стану здоров'я всіх планувальників кожні 60 секунд для цього конкретного вузла NUMA, переконуючись, що планувальник застряг або ні.

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

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

Ваша найкраща ставка - спершу налаштувати параметр " Максимальна ступінь паралельності ". За замовчуванням 0 засоби SQL Server може використовувати всі доступні процесори для паралельної обробки і там, вичерпавши всі робочі потоки.

Є багато причин, які можуть призвести до виснаження робочих ниток:

• Великі довгі ланцюги блокування, які призводять до того, що у SQL Server не вистачає робочих ниток
• Широкий паралелізм також призводить до виснаження робочих ниток
• Постійне очікування будь-якого типу «замка» - спинових замків, засувок. Осиротілий спинлок - приклад.

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

Також настійно рекомендую почати збирати інформацію про статистику щодо екземпляра сервера бази даних.

Причин може бути кілька. Швидше за все, це те, що ви залишилися без робітників. Див max_worker_threads. Ця умова називається «трудова затяжність». Робітники можуть бути викрадені будь-яким численним способом (жоден з яких не призведе до високої завантаженості процесора, btw), як, наприклад, заблоковано багато запитів або робити дурні речі в CLR (наприклад, HTTP-запити).

Симптом, який ви бачите, є жертвою проблеми, а не причиною. Ми не можемо рекомендувати рішення, не знаючи причини. Вам потрібно зібрати лічильники парфумів, DMV та перевірити ERRORLOG для отримання додаткової інформації.