Tenho experimentado lentidão aleatória e inesperada em um SQL Server virtual que não posso atribuir à carga de trabalho, ao armazenamento ou à CPU (na verdade, continuou depois que o host foi evacuado de outras VMs).
eu suspeitopoderestar relacionado à configuração NUMA - particularmente como a memória física é mapeada.
A execução coreinfomostra o seguinte custo de acesso entre nós NUMA:
Approximate Cross-NUMA Node Access Cost (relative to fastest):
00 01
00: 1.0 1.3
01: 1.4 1.5
O que parece estranho - eu esperava que 01-01 estivesse mais próximo de 1,0 e que a penalidade estivesse entre os nós.
Acho que isso sugere que a memória está sendo alocada no primeiro nó pNUMA no VMware e pode estar causando penalidade de desempenho para acesso à memória do segundo nó vNUMA.
Com o SQL Server reconhecendo NUMA, ele poderia estar fazendo suposições sobre o impacto do acesso à memória entre NUMA que afetaria o desempenho nesse cenário (ou seja, tentar manter o acesso em um nó e evitar o acesso entre NUMA)?
Há alguma etapa que eu possa seguir para tentar garantir que a memória esteja sendo alocada uniformemente entre os nós pNUMA?
O anfitrião é o seguinte:
- vSphere 6.7.0
- 2x Xeon Gold 5217 (8 núcleos)
- Memória total de 768 GB
A VM é a seguinte:
- 12x vCPU (3 núcleos por soquete = 4 soquetes)
- 320 GB de RAM
- Janelas 2012 R2
- SQL Server 2016 Empresarial
EDIT: x-mem está mostrando o seguinte que não corresponde acoreinfo
xmem-win-x64.exe -j6 -s -R -l -f test.csv -n5
00 01
00 1.21124 1.18519
01 1.19831 1.18695