Aguarde Aguarde Aguarde
Embora os aspectos de desempenho e licenciamento sejam interessantes, eles não são o único aspecto de uma carga de trabalho a considerar.
Uma coisa que pode afetar a escolha do processador são os threads de trabalho.
Linhas de trabalho?
Sim amigo! São as coisas que o SQL Server usará para executar suas consultas e fazer todo o material de segundo plano necessário para manter as coisas em forma.
Quando você correr para fora de segmentos de trabalho, você bateu ThreadPool espera
GRUPO DE DISCUSSÃO?
GRUPO DE DISCUSSÃO. Essa é uma das esperas mais desagradáveis que você pode ter no servidor, juntamente com RESOURCE_SEMAPHORE e RESOURCE_SEMAPHORE_QUERY_COMPILE . Mas essas são esperas de memória, e esta é uma questão de CPU.
Então, de volta ao motivo pelo qual isso é uma loucura.
É assim que o SQL Server calcula os threads de trabalho :
Observe como a contagem de núcleos duplicados não duplica o Max Worker Threads e você obtém o mesmo número com 1 núcleo do que com 4 núcleos? A equação é:512 + ((logical CPUs - 4) * 16)
É uma pena, porque quando a contagem de núcleos aumenta, a velocidade do relógio geralmente diminui para uma ou duas gerações atrás.
Examinar qualquer linha recente de chips Intel mostrará uma tendência semelhante.
Como sei quantos threads eu preciso?
Isso vai depender muito de:
- Número de usuários
- Número de consultas paralelas
- Número de consultas seriais
- Número de bancos de dados e sincronização de dados (espelhamento, AGs, backups para envio de logs)
- Se você deixar MAXDOP e CTFP nos padrões
Se você não está ficando sem hoje, provavelmente está bem.
Mas como você sabe se é?
Existem boas perguntas, e ótimas, e deixe-me dizer uma coisa, que é uma GRANDE PERGUNTA .
THREADPOOL pode se manifestar como problemas de conexão e você pode ver mensagens no log de erros sobre não conseguir gerar um encadeamento .
Você também pode consultar as estatísticas de espera do seu servidor usando uma ferramenta gratuita como sp_Blitz ou sp_BlitzFirst (divulgação completa, contribuo para este projeto).
EXEC sp_Blitz
EXEC sp_BlitzFirst @SinceStartup = 1
Não posso simplesmente aumentar o Max Worker Threads?
O aumento do MWT pode levar a maiores SOS_SCHEDULER_YIELDesperas.
Esse não é o fim do mundo, mas pense nisso como adicionar um buncha que grita crianças à aula de um professor.
De repente, será mais difícil para cada criança chamar atenção.
Quando um processo esgotar seu quantum de 4ms , haverá potencialmente mais threads à frente esperando para entrar na CPU.
O desempenho pode parecer o mesmo.
Como posso usar menos threads de trabalho?
Você cruel [substantivo] de um [substantivo], esses são trabalhadores com famílias para sustentar! Hipotecas! Sonhos!
Mas tudo bem, tem que respeitar a linha de fundo. Você é o chefe.
O ponto mais fácil para começar é alterar configurações como MAXDOP e Cost Threshold For Parallelism dos padrões.
Se você tiver dúvidas sobre como defini-las, acesse aqui:
Depois disso, seu trabalho fica muito mais difícil. Você precisa descobrir o que está usando todos esses tópicos. Às vezes, você pode fazer isso observando suas estatísticas de espera.
Mais especificamente, se você tiver altas esperas no paralelismo ( CXPACKET) E altas esperas nos bloqueios (LCK_ ), poderá estar executando longas cadeias de bloqueio envolvendo consultas paralelas.
Você sabe o que fede? Enquanto todas essas consultas paralelas estão aguardando para obter seus bloqueios, elas não devolvem seus threads alocados.
Você quase consegue ouvir a VM de quatro núcleos que seu administrador garantiu que era mais do que suficiente para qualquer carga de trabalho sem ar, hein?
Infelizmente, o tipo de consulta e ajuste de índice que você precisa fazer para resolver essas coisas está além do escopo da pergunta.
Espero que isto ajude!