Olá comunidade do SQL Server,
Estou tentando aprofundar minha compreensão dos threads de trabalho do SQL Server, especialmente no que diz respeito à configuração máxima de threads de trabalho em um sistema OLTP ocupado. Atualmente estou trabalhando com o sys.dm_os_threadsDMV e explorando a melhor forma de otimizar o gerenciamento de threads em nosso servidor.
Meu entendimento atual é que o SQL Server gerencia automaticamente os threads de trabalho com base na carga de trabalho do sistema se a configuração padrão de máximo de threads de trabalho permanecer inalterada. O SQL Server pode alocar mais threads de trabalho para lidar com cargas de trabalho maiores e pode recuperar ou destruir esses threads quando as tarefas forem concluídas, embora isso possa não ocorrer imediatamente.
No entanto, não tenho certeza se meu entendimento está correto, principalmente quando se trata de situações em que o SQL Server pode ter atingido seu limite para a criação de novos threads. Se isso acontecer e ainda houver novas solicitações recebidas, isso poderá resultar em uma condição de 'agendador de impasse'? Recentemente, enfrentamos esse problema em nosso ambiente e estou tentando entender se essa pode ser a causa.
Diante desse contexto, tenho algumas perguntas:
- Em um sistema OLTP ocupado, deveríamos considerar alterar a configuração máxima de threads de trabalho de seu valor padrão calculado pela fórmula da Microsoft?
- Se devêssemos alterá-lo, deveria ser para um número maior que o padrão?
- Qual a melhor forma de determinar o número ideal de threads de trabalho máximos para nosso ambiente específico para evitar o problema do 'agendador de deadlock'?
Seus insights ou conselhos sobre este assunto seriam muito apreciados. Obrigado.
Isto está certo.
Poderia, depende inteiramente da situação. Supondo que o sistema esteja funcionando e atingindo um limite de recursos, novas conexões falharão, pois é necessário um thread para atendê-las. Normalmente é isso que você começará a ver, junto com o servidor sendo "lento" ou "lento", mas isso não é um requisito.
Agendadores em impasse acontecem quando nenhum trabalho atual avança, isso se deve quase exclusivamente ao bloqueio.
Eu não faria isso, principalmente devido ao fato de que atualmente você não sabe por que teve um problema. Digamos que esteja bloqueando (novamente, quase sempre está). Você aumenta os threads de trabalho. Agora, em vez de ter um despejo do agendador em conflito aos 5 minutos, você obtém um aos 7. Ninguém realmente causou o problema, então a "solução" obviamente não funcionará. Existem advertências para isso? Claro. Esses são casos super extremos? Sim.
Há várias outras coisas a serem consideradas, por exemplo, aumentar artificialmente a contagem de threads pode fazer com que todos os outros processos (não apenas SQL) e todas as outras consultas sejam executadas mais lentamente. Cada thread precisa de uma fatia do bolo da CPU. Se houver 800 threads em 4 núcleos, eles serão suficientes. Se houver 2.400 threads em 4 núcleos, você obterá ainda menos (supondo que os threads precisem funcionar, apenas girar 2.400 threads não resultará em nada se eles não tiverem algo para fazer).
Se não, o número padrão é bastante bom, em geral. O número de threads em si (assumindo que não foi definido como extremamente baixo para ajudar a forçar a situação) não é o problema. Causa raiz do problema do agendador em conflito primeiro. Alterar o valor do MWT quase sempre não ajuda e é mais um obstáculo.