Estamos começando a provisionar um conjunto de servidores físicos para um cluster virtual de nós do SQL Server 2016 no VMware. Estaremos utilizando licenças Enterprise Edition.
Planejamos configurar 6 nós, mas há um pouco de debate sobre qual a maneira ideal de provisionar os servidores físicos com relação à velocidade do clock da CPU versus a contagem de núcleos da CPU.
Eu sei que isso depende em grande parte do volume de transações e do número de bancos de dados armazenados entre outros fatores específicos do software, mas há uma regra geral recomendada?
Por exemplo, um servidor físico duplo de 8 núcleos e 3,2 GHz (16 núcleos) é mais preferencial do que um servidor duplo de 16 núcleos e 2,6 GHz (32 núcleos)?
Alguém já se deparou com um white paper que aprofunde esse tipo de tópico?
A regra geral é manter a contagem de núcleos o mais baixa possível e a velocidade do processador o mais alta possível. A matemática de licenciamento disso prova o ponto em ~ $ 7.500 USD por núcleo para Enterprise Edition.
Comprar o hardware correto pode se pagar em custos de licenciamento reduzidos. Consulte Seleção de processador para SQL Server por Glenn Berry. É um ótimo recurso sobre como escolher um processador para o SQL Server.
Depois de levar em consideração a estrutura de licenciamento por núcleo do SQL Server, faz sentido sempre usar a velocidade de processador mais rápida disponível, independentemente do tipo de carga de trabalho, seja OLTP ou analítica. Ter a velocidade de núcleo mais rápida possível nunca será um problema. Aumente a contagem de núcleos conforme necessário, mas nunca faça isso reduzindo a velocidade do núcleo.
Em outras palavras, não pense em processadores de 16 x 2,2 Ghz sendo o mesmo que processadores de 8 x 4,4 Ghz. A economia de custos de hardware do uso de processadores de 2,2 Ghz sobre os processadores de 4,4 Ghz provavelmente será de no máximo US$ 10.000 (para uma máquina típica de dois processadores baseada em Xeon). no entanto, a mudança de 8 núcleos para 16 núcleos com o SQL Server Enterprise Edition provavelmente custará US$ 60.000 a mais em taxas de licenciamento. Em outras palavras, você pode economizar US$ 10.000 em custos de hardware, mas perderá US$ 50.000 extras em licenciamento.
Se você decidir que precisa de muito músculo de processamento paralelo e decidir que precisa de 32 núcleos para a tarefa em mãos, usar os núcleos mais rápidos pagará dividendos em tempo de processamento reduzido. Ninguém vai te culpar por isso.
Dito tudo isso, se a escolha for uma CPU ou mais de uma CPU, sempre vá com mais de uma . A execução do SQL Server (ou qualquer DBMS) em uma única CPU pode causar todos os tipos de problemas, pois a capacidade de operações simultâneas é muito limitada.
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 ser considerado.
Uma coisa que pode ter um impacto na escolha do processador são os threads de trabalho.
Tópicos do Trabalhador?
Sim amigo! Eles são as coisas que seu SQL Server usará para executar suas consultas e fazer todas as coisas em segundo plano necessárias para manter as coisas em forma.
Quando você fica sem threads de trabalho, você pressiona THREADPOOL espera
GRUPO DE DISCUSSÃO?
GRUPO DE DISCUSSÃO. Esta é uma das esperas mais desagradáveis que você pode ter em seu servidor, junto 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 porquê isso é wack wiggity.
É assim que o SQL Server calcula os threads de trabalho :
Observe como duplicar a contagem de núcleos não duplica o Max Worker Threads e você obtém o mesmo número com 1 núcleo e com 4 núcleos? A equação é:
512 + ((logical CPUs - 4) * 16)Isso é uma pena, porque quando a contagem de núcleos aumenta, a velocidade do clock geralmente cai para uma ou duas gerações atrás.
Dando uma olhada em qualquer linha recente de chips Intel mostrará uma tendência semelhante.
Como saber quantos fios preciso?
Isso vai depender muito de:
Se você não está ficando sem eles hoje, provavelmente está bem.
Mas como você sabe se você é?
Há boas perguntas, e há grandes perguntas, e deixe-me dizer uma coisa, essa é uma ÓTIMA PERGUNTA .
THREADPOOL pode se manifestar como problemas de conexão , e você pode ver mensagens no log de erros sobre não poder gerar um thread .
Você também pode ver as estatísticas de espera do seu servidor usando uma ferramenta gratuita como sp_Blitz ou sp_BlitzFirst (divulgação completa, eu contribuo para este projeto).
EXEC sp_BlitzEXEC sp_BlitzFirst @SinceStartup = 1Não posso simplesmente aumentar o Max Worker Threads?
O aumento do MWT pode levar ao aumento das
SOS_SCHEDULER_YIELDesperas.Isso não é o fim do mundo, mas pense nisso como adicionar um monte de crianças gritando à aula de um professor.
De repente, vai ser mais difícil para cada criança chamar a atenção.
Quando um processo esgota seu quantum de 4ms , potencialmente haverá mais threads à sua frente esperando para entrar na CPU.
O desempenho pode parecer o mesmo.
Como posso usar menos threads de trabalho?
Você [substantivo] cruel de um [substantivo], esses são trabalhadores com famílias para sustentar! Hipotecas! Sonhos!
Mas tudo bem, tenho que respeitar a linha de fundo. Você é o chefe.
O lugar 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 configurá-los, acesse aqui:
Algoritmo de configuração MAXDOP para SQL Server
Por que o limite de custo para paralelismo não deve ser definido como 5
Depois disso, seu trabalho fica muito mais difícil. Você tem que 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ê tem altas esperas no paralelismo (
CXPACKET) E altas esperas nos bloqueios (LCK_), então você pode estar se deparando com longas cadeias de bloqueio envolvendo consultas paralelas.Você sabe o que fede? Enquanto todas essas consultas paralelas estão esperando para obter seus bloqueios, elas não devolvem seus threads alocados.
Você quase pode ouvir aquela VM de quatro núcleos que seu administrador garantiu que era mais do que suficiente para qualquer carga de trabalho sem fôlego, hein?
Infelizmente, o tipo de consulta e ajuste de índice que você precisa fazer para resolver essas coisas está além do escopo da questão.
Espero que isto ajude!
Resposta do wiki da comunidade :
Resumindo: a maioria das cargas de trabalho para SQL Server são OLTP, que se beneficiam de velocidades de clock mais altas porque é uma operação serial.
A menos que você esteja projetando especificamente para um sistema massivamente paralelo, as velocidades de clock sempre prevalecerão. Existem casos extremos, mas essa é a resposta de 95% do tempo. O fato de acabar custando menos também é uma coisa legal.
A resposta se resume a isso: depende do seu caso de uso.
Por exemplo, eu tenho um computador quad core, mas o compilador ESP8266 usa apenas 25% da minha CPU porque foi projetado para usar apenas um núcleo. Se eu tivesse 1 núcleo rápido, isso seria mais ideal.