He estado experimentando desaceleraciones inesperadas y aleatorias de un servidor SQL virtual que no puedo atribuir a la carga de trabajo, el almacenamiento o la CPU (de hecho, continuó después de que el host fue evacuado de otras máquinas virtuales).
lo sospechopodríaestar relacionado con la configuración NUMA, particularmente con cómo se asigna la memoria física.
La ejecución coreinfomuestra el siguiente costo de acceso al nodo entre NUMA:
Approximate Cross-NUMA Node Access Cost (relative to fastest):
00 01
00: 1.0 1.3
01: 1.4 1.5
Lo que parece extraño: hubiera esperado que 01-01 estuviera más cerca de 1.0 y que la penalización fuera entre nodos.
Creo que esto sugiere que se está asignando memoria en el primer nodo pNUMA de Vmware y podría estar provocando una penalización en el rendimiento del acceso a la memoria desde el segundo nodo vNUMA.
Dado que SQL Server es compatible con NUMA, ¿podría estar haciendo suposiciones sobre el impacto del acceso a la memoria entre NUMA que afectaría el rendimiento en este escenario (es decir, intentar mantener el acceso en un nodo y evitar el acceso entre NUMA)?
¿Hay algún paso que pueda seguir para intentar garantizar que la memoria se asigne uniformemente entre los nodos pNUMA?
El anfitrión es el siguiente:
- vSphere 6.7.0
- 2x Xeon Gold 5217 (8 núcleos)
- 768 GB de memoria total
La máquina virtual es la siguiente:
- 12x vCPU (3 núcleos por zócalo = 4 zócalos)
- 320 GB de RAM
- Ventanas 2012 R2
- SQL Server 2016 Empresa
EDITAR: x-mem muestra lo siguiente que no coincide concoreinfo
xmem-win-x64.exe -j6 -s -R -l -f test.csv -n5
00 01
00 1.21124 1.18519
01 1.19831 1.18695