Необходимо понимать ошибку выполнения параллельного запроса

Сегодня мы испытали снижение производительности на нашем производственном сервере 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, вам также будет указано расположение файла дампа.

Теперь вернемся к проблеме:

Для каждого узла NUMA имеется 1 поток монитора планировщика, и, поскольку у вас 2 узла NUMA, будет 2 потока монитора планировщика, которые отвечают за проверку работоспособности всех планировщиков каждые 60 секунд для этого конкретного узла NUMA, обеспечивая при этом, что планировщик застрял или не.

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

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

Лучше всего сначала настроить максимальную степень параллелизма . Значение по умолчанию 0 означает, что SQL Server может использовать все доступные процессоры для параллельной обработки и исчерпать все рабочие потоки.

Есть много причин, которые могут привести к исчерпанию рабочих потоков:

• Обширные длинные блокирующие цепочки, приводящие к тому, что в SQL Server заканчиваются рабочие потоки
• Обширный параллелизм также ведет к исчерпанию рабочих потоков
• Обширное ожидание любого типа «замков» - спин-замков, защелок. Сиротский спинлок является примером.

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

Кроме того, настоятельно рекомендуем вам начать сбор статистических данных об экземпляре сервера базы данных.

Там может быть несколько причин. Скорее всего, у вас не было работников. См max_worker_threads. Условие называется «стратация работника». Рабочие могут быть украдены любым из множества способов (ни один из которых не приведет к высокой загрузке ЦП, кстати), например, блокирование множества запросов или выполнение глупых действий в CLR (например, HTTP-запросы).

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