Precisa entender o erro de execução de consulta paralela

Hoje, experimentamos uma degradação no desempenho em nosso servidor sql de produção. Durante o tempo em que isso ocorreu, registramos vários "The query processor could not start the necessary thread resources for parallel query execution"erros. A leitura que fiz sugere que isso tem a ver com quantas CPUs usar ao executar uma consulta complexa. No entanto, quando eu verifiquei durante a interrupção nossa CPU Utilization was only at 7%. Há algo mais a que isso possa estar se referindo também que ainda não encontrei? Isso é provavelmente o culpado pela degradação do desempenho ou estou perseguindo um arenque vermelho?

Meus valores sp_configure para isso são os seguintes:

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

Alguns meses atrás, enfrentei uma situação semelhante em que a configuração MAXDOP era padrão e uma consulta de execução esgotava todos os threads de trabalho.

Como Remus apontou, isso é chamado de privação de threads de trabalho .

Haverá um despejo de memória criado no seu servidor quando essa condição ocorrer.

Se você estiver no 2008R2 + SP1 e superior, sys.dm_server_memory_dumpstambém fornecerá o local do arquivo de despejo.

Agora, de volta ao problema:

Há um encadeamento de monitor do agendador por nó NUMA e, como você possui 2 nós NUMA, haverá 2 encadeamentos de monitor agendadores responsáveis ​​pela verificação de integridade de todos os agendadores a cada 60 segundos para esse nó NUMA específico, assegurando que o agendador esteja travado ou não.

Cada vez que uma nova solicitação de trabalho é retirada da fila de trabalho dos agendadores, o contador de processos de trabalho é incrementado. Portanto, se o planejador tiver uma solicitação de trabalho na fila e não processar uma das solicitações de trabalho em 60 segundos, o planejador será considerado travado.

Devido a uma consulta de fuga ou paralelismo extensivo, surge uma condição de encadeamentos de trabalho esgotados, pois todos os encadeamentos são ocupados por essa consulta de fuga única ou bloqueio prolongado excessivo e nenhum trabalho pode ser feito a menos que o processo incorreto seja interrompido.

Sua melhor aposta é ajustar primeiro a configuração de Max Degree of Parallelism . Padrão de0 , o SQL Server pode usar todas as CPUs disponíveis para processamento paralelo e esgotar todos os threads de trabalho.

Há muitos motivos que podem levar à exaustão dos threads de trabalho:

• Cadeias de bloqueio longas e extensas, causando o SQL Server ficar sem threads de trabalho
• Paralelismo extenso também levando ao esgotamento dos threads de trabalho
• Espera extensa por qualquer tipo de "trava" - fechos, trincos. Um spinlock órfão é um exemplo.

Consulte a minha resposta aqui que mostrará como você pode calcular o valor MAXDOP para sua instância do servidor.

Além disso, é altamente recomendável que você comece a coletar informações de estatísticas de espera sobre a instância do servidor de banco de dados.

Pode haver várias razões. O mais provável é que você estivesse sem trabalhadores. Vejomax_worker_threads . A condição é chamada de 'extravio do trabalhador'. Os trabalhadores podem ser roubados por qualquer um dos vários meios (nenhum dos quais resultaria em alta utilização da CPU, btw), como ter muitas solicitações bloqueadas ou fazer coisas estúpidas no CLR (por exemplo, solicitações HTTP).

O sintoma que você vê é vítima do problema, não a causa. Não podemos recomendar uma solução sem o conhecimento da causa. Você precisa coletar contadores de perf, DMVs e verificar o ERRORLOG para obter mais informações.