Ich habe zufällige, unerwartete Verlangsamungen eines virtuellen SQL-Servers festgestellt, die ich nicht auf die Arbeitslast, den Speicher oder die CPU zurückführen kann (tatsächlich dauerte dies noch an, nachdem der Host von anderen VMs evakuiert wurde).
Ich vermute eskönntemit der NUMA-Konfiguration zusammenhängen – insbesondere mit der Art und Weise, wie der physische Speicher zugeordnet wird.
Beim Ausführen coreinfowerden die folgenden NUMA-Knotenzugriffskosten angezeigt:
Approximate Cross-NUMA Node Access Cost (relative to fastest):
00 01
00: 1.0 1.3
01: 1.4 1.5
Das scheint seltsam – ich hätte erwartet, dass 01-01 näher bei 1,0 liegt und die Strafe zwischen den Knoten liegt.
Ich denke, dies deutet darauf hin, dass dem ersten pNUMA-Knoten auf VMware Speicher zugewiesen wird und dies möglicherweise zu Leistungseinbußen beim Speicherzugriff vom zweiten vNUMA-Knoten führt.
Könnte SQL Server, da es NUMA-fähig ist, Annahmen über die Auswirkungen von NUMA-übergreifenden Speicherzugriffen treffen, die sich in diesem Szenario auf die Leistung auswirken würden (z. B. indem versucht wird, den Zugriff auf einem Knoten zu belassen und NUMA-übergreifende Zugriffe zu vermeiden)?
Gibt es irgendwelche Schritte, die ich unternehmen kann, um sicherzustellen, dass der Speicher gleichmäßig auf die pNUMA-Knoten verteilt wird?
Gastgeber ist wie folgt:
- vSphere 6.7.0
- 2x Xeon Gold 5217 (8 Kerne)
- 768 GB Gesamtspeicher
Die VM sieht wie folgt aus:
- 12x vCPU (3 Kerne pro Sockel = 4 Sockel)
- 320 GB RAM
- Windows 2012 R2
- SQL Server 2016 Enterprise
EDIT: x-mem zeigt das folgende an, was nicht übereinstimmt mitcoreinfo
xmem-win-x64.exe -j6 -s -R -l -f test.csv -n5
00 01
00 1.21124 1.18519
01 1.19831 1.18695