Utilização muito desigual da CPU com o SQL Server 2012 em um computador com 2 processadores e 16 núcleos / processador

Depois de instalar o SQL Server Enterprise 2012 com o modelo de licença Server + Cal, em um computador com 2 processadores, cada um com 16 núcleos (e sem hyperthreading) e colocando o servidor sob carga extremamente pesada, os 16 núcleos no primeiro processador foram muito subutilizados. os primeiros 4 núcleos na 2ª CPU foram muito utilizados e os últimos 12 núcleos não foram usados ​​(por causa do limite de 20 núcleos para esta versão do servidor sql). A utilização total da CPU foi exibida em cerca de 25%. Infelizmente, o servidor sofreu um desempenho extremamente ruim, mesmo que as tarefas fossem distribuídas igualmente entre os 20 núcleos e não teriam sido tão ruins.

O Windows Server estava sendo executado em uma imagem virtual do VMWare no ESX Server, mas toda a CPU foi alocada para o servidor Windows.

Tentamos alterar as configurações de afinidade (por exemplo, alocar a maioria dos núcleos para a CPU e os demais para E / S), mas isso não ajudou a resolver os problemas de desempenho.

A atualização da edição do produto para o SQL Server Enterprise Core 2012 não apenas permitiu que o SQL Server utilizasse os 12 núcleos não utilizados anteriormente no 2º processador, mas também resultou em uma distribuição muito mais uniforme de tarefas em todos os processadores. Para superar o atraso de solicitações, a utilização da cpU saltou para cerca de 90% e depois caiu para cerca de 33% quando foi capturada, mas o desempenho melhorou drasticamente desde que fizemos o failover para a versão recém-atualizada E os problemas de desempenho desapareceram.

Fiquei me perguntando se alguém sabe o que poderia causar o SQL Server distribuir a carga de maneira desigual, confiando quase exclusivamente nos 4 primeiros núcleos do 2º processador com 12 núcleos ociosos e alocando apenas algumas tarefas para cada um dos 16 núcleos no primeiro processador. Além disso, existe alguma maneira de distribuirmos a carga de maneira mais uniforme entre os 20 núcleos que estavam sendo usados ​​sem a atualização da edição do produto?

O outro lado dessa pergunta é o que a atualização do produto fez com que o SQL Server começasse a distribuir uniformemente a carga por todos os núcleos que reconheceu?

Agradeço a todas as dicas para responder a essas perguntas e / ou links que podem me ajudar a entender melhor como entender o que estava acontecendo.

O desempenho desigual provavelmente foi uma combinação do limite de 20 núcleos combinado com a maneira como o servidor sql agenda os threads nas máquinas NUMA. Infelizmente, o SQL Server 2012 não usa nenhuma inteligência para decidir quais 20 núcleos utilizar, resultando em um número desequilibrado de núcleos por nó NUMA. Com 32 núcleos espalhados por 2 nós NUMA, você provavelmente terminará em uma divisão 16/4. Isso é problemático porque o SQL tentará equilibrar a atividade igualmente entre os nós NUMA de maneira alternada (assumindo que você não está forçando a afinidade com o administrador de recursos).

No seu caso, 1/2 da carga é atribuída a 4 núcleos e 1/2 a 16 núcleos. O gargalo no nó de 4 núcleos atua efetivamente como um acelerador, limitando a capacidade da máquina a 2x 4 núcleos = 8 núcleos = 25% de uso da CPU.

Depois de atualizar para a edição principal, o sql utilizou todos os 32 núcleos em 2 nós em uma (divisão 16/16). Desempenho melhorado, etc.

Uma opção que poderia ter melhorado seu desempenho seria utilizar o administrador de recursos do servidor sql para afinitar a maioria de sua carga de trabalho em um nó numa. Por exemplo, você pode criar um pool de recursos WEB_APP e afinitizá-lo para executar apenas no nó numa de 16 núcleos. A carga atribuída ao pool WEB_APP pode utilizar 50% da capacidade do servidor, mais a capacidade restante de 12,5% do nó de 4 núcleos.

A outra opção seria limitar os núcleos disponíveis para o servidor sql a apenas 10 de cada nó numa.