Por que o uso da CPU é tão assimétrico em nossa caixa do SQL Server de 8 cpu?

Question

Tenho notado que o uso da CPU em nosso servidor de banco de dados de 8 CPUs, executando o SQL Server 2008, não está balanceado.

Aqui estão as médias de 1 dia para um dia aleatório de um tempo atrás, o que é típico e consistentemente assimétrico:

9, 15, 10, 21, 18, 21, 14, 9

(apenas miniatura aqui, porque a imagem é muito alta, mas clique na imagem em tamanho real)

Comparado com nossos servidores web de 4 CPUs, que são quase exatamente e perfeitamente equilibrados o tempo todo , isso me pareceu estranho.

Agora, esse é um servidor dedicado, portanto, a única coisa que está sendo executado nele é o SQL Server 2008 (e a indexação de texto completo integrada, que usamos bastante), então não tenho certeza O uso da CPU seria tão assimétrico . Pensamentos?

    

Answer 1

Como seus arquivos / grupos de arquivos são configurados?

Vou plagiar eu mesmo :

Mais uma ideia sobre IO: tivemos o cuidado de configurar nossas maiores tabelas mais usadas para estar em grupos de arquivos com vários arquivos. Um dos aprimoramentos de desempenho disso é que o SQL enviará solicitações para cada arquivo no grupo de arquivos - portanto, se BigOverUsedTable estiver em FileGroup1 e FileGroup1 tiver quatro arquivos nele e seu banco de dados tiver 8 núcleos, ele usará quatro núcleos para fazer "select" grande número esmagando consulta desagradável de BigOverUsedTable "- ao contrário, ele usará apenas uma CPU. Nós temos essa idéia neste artigo do MSDN:

link

Do TFA:

"Grupos de arquivos usam threads paralelos para melhorar o acesso aos dados. Quando uma tabela é acessada sequencialmente, o sistema cria um thread separado para cada arquivo em paralelo. Quando o sistema executa uma varredura de tabela para uma tabela em um grupo de arquivos com quatro arquivos, usa quatro segmentos separados para ler os dados em paralelo. Em geral, usar vários arquivos em discos separados melhora o desempenho. Muitos arquivos em um grupo de arquivos podem causar muitos encadeamentos paralelos e criar gargalos. "

Temos quatro arquivos em nosso grupo de arquivos em uma máquina de 8 núcleos devido a esse conselho. Está funcionando bem.

Edit: isso tem outra (possivelmente) melhor resposta agora. Os gráficos estavam fora de escala - se você olhar de perto, cada processador está na verdade com cerca de 20% de carga conforme os uzbones apontam.

Editar: Podemos realmente dizer que o uso de vários grupos de arquivos ajuda, porque não colocamos todas as nossas tabelas no grupo de arquivos com quatro arquivos. Grandes consultas no grupo de arquivos "arquivo único" usam apenas uma CPU, mas as consultas na tabela no grupo de arquivos de quatro arquivos atingem 4 CPUs.

    

Answer 2

As escalas são diferentes em todas elas, além de um pico em 4 dos gráficos. Suas médias seriam de 10 a 25%.

    

Answer 3

Verifique isso:

link

O SQL pode estar apenas gravando em um punhado de arquivos e cada processador está usando cada arquivo.

    

Answer 4

A primeira coisa que eu verifico para coisas assim são os drivers. Eu tive muitos problemas com a formação de equipes de rede e com os drivers iSCSI MPIO permanecendo em núcleos específicos. Eu aposto que esse não é o problema aqui, já que parece que está acontecendo em 4 núcleos - eu normalmente só vejo isso com 2 núcleos. Vou perguntar ao redor para ver se alguém viu isso tão longe.

Eu também vi isso com caixas NUMA onde há uma incompatibilidade de memória - digamos que metade dos núcleos estão ligados a 16GB de ram e os outros estão ligados até 8. Google para IBM x460 NUMA se você quiser ver algumas informações engraçadas sobre isso. Os modelos 460 e relacionados permitem encadear vários servidores para criar uma grande relevância - com o aumento de escala versus a entrada no blog. Eles são máquinas incríveis.

    

Answer 5

Porque liberar caches de CPU é tão incrivelmente caro que o kernel tenta evitá-lo a todo custo.

(Nota: Pelo menos o Linux faz; ficaria surpreso se o Windows não tivesse o mesmo comportamento)