Antes de postar esta pergunta, leia os seguintes artigos.
- Máx. Worker Threads e quando você deve alterá-lo por Sakthivel Chidambaram
- Meus threads de trabalho reais estão excedendo o valor sp_configure 'max worker threads'? por Tom Stringer
- Como você mede a pressão da CPU? por Thomasda
- DMVs do SQLOS continuam por Slavao
Estou familiarizado com a investigação de problemas de alta contagem de threads observando os seguintes itens (não abrangentes):
- Configuração de maxdop
- Limite de custo da configuração de paralelismo
- Pressão da CPU
- Comprimento da fila do trabalhador
- Plano de execução
Esta investigação pode levar horas antes de eu decidir fazer uma mudança. O que posso fazer em curto prazo para que as solicitações não estejam aguardando a atribuição de threads de trabalho?
Usamos o SCOM para monitorar muitos aspectos do SQL Server e este é um deles. Eu entendo que isso é mais uma mensagem informativa, mas ver é consistentemente do mesmo servidor nos dá a oportunidade de ver as coisas que listei acima. O que estou tentando descobrir da comunidade, se eles tomam determinada ação (pode ser temporário, até que a avaliação completa seja feita) se work_queue_counté constantemente maior que zero quando o alerta é acionado pelo SCOM. Há momentos em que é fácil detectar uma única consulta que está consumindo muitos encadeamentos, mas nem sempre.
Fórmula padrão para [máximo de trabalhadores] (com ou abaixo de 64 CPUs lógicas): 16*(CPUs lógicas - 4) + 512
Aqui estão duas possíveis justificativas se você quiser aumentar [máximo de trabalhadores]. Se a CPU não estiver saturada quando ocorrerem downgrades DOP devido à contagem de trabalhadores reservados, as consequências negativas serão limitadas. YMMV.