Estamos começando a provisionar um conjunto de servidores físicos para um cluster virtual de nós do SQL Server 2016 no VMware. Utilizaremos licenças da 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 contagem de núcleos da CPU.
Sei que isso depende muito 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 a um servidor duplo de 16 núcleos e 2,6 GHz (32 núcleos)?
Alguém já se deparou com um white paper que investiga mais esse tipo de tópico?
fonte
Respostas:
A regra geral é manter a contagem de núcleos o mais baixa possível e a velocidade do processador a mais alta possível. A matemática do licenciamento mostra o ponto em ~ $ 7.500 USD por núcleo para a Expensive Edition.
A compra do hardware correto pode se pagar com custos reduzidos de licenciamento. Consulte Seleção de processador para SQL Server, de 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 usar sempre a velocidade mais rápida do processador disponível, independentemente do tipo de carga de trabalho, seja OLTP ou analítica. Ter a velocidade do 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 que os processadores de 16 x 2,2 Ghz sejam iguais aos de 8 x 4,5 Ghz. A economia de custo do uso dos processadores de 2.2Ghz em relação aos 4.5Ghz provavelmente será de aproximadamente US $ 10.000 (para uma máquina de dois processadores típica baseada em Xeon). O salto de 8 para 16 núcleos com o SQL Server Enterprise Edition provavelmente custará mais de US $ 60.000 em taxas de licenciamento. Em outras palavras, você pode economizar US $ 10.000 em custos de hardware, mas perderá US $ 50.000 adicionais em licenciamento.
Se você decidir que precisa de muito músculo de processamento paralelo e precisar de 32 núcleos para a tarefa em mãos, seguir os núcleos mais rápidos pagará dividendos no tempo de processamento reduzido. Ninguém o culpará por isso.
Dito tudo isso, se a escolha for uma CPU ou mais de uma CPU, sempre use mais de uma . A execução do SQL Server (ou qualquer DBMS) em uma única CPU pode causar todos os tipos de problemas, uma vez que o recurso para operações simultâneas é bastante limitado.
fonte
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:
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_BlitzEXEC sp_BlitzFirst @SinceStartup = 1Nã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:
Algoritmo de configuração MAXDOP para SQL Server
Por que o limite de custo do paralelismo não deve ser definido como 5
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!
fonte
Resposta do wiki da comunidade :
A longa e a curta são: A maioria das cargas de trabalho para o SQL Server são OLTP, o que se beneficia 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 do relógio sempre vencerão. Existem casos extremos, mas essa é a resposta em 95% do tempo. O fato de acabar custando menos também é uma coisa boa.
fonte
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 apenas para usar um núcleo. Se eu tivesse um núcleo rápido, isso seria mais ideal.
fonte