Я столкнулся со случайными неожиданными замедлениями работы виртуального SQL-сервера, которые я не могу связать с рабочей нагрузкой, хранилищем или ЦП (на самом деле, замедление продолжалось после того, как хост был эвакуирован с других виртуальных машин).
Я подозреваю этомощьбыть связано с конфигурацией NUMA, в частности с тем, как отображается физическая память.
Выполнение coreinfoпоказывает следующую стоимость доступа к узлам NUMA:
Approximate Cross-NUMA Node Access Cost (relative to fastest):
00 01
00: 1.0 1.3
01: 1.4 1.5
Что кажется странным — я ожидал, что 01-01 будет ближе к 1,0, а штраф будет между узлами.
Я думаю, это говорит о том, что память выделяется на первом узле pNUMA в Vmware и может вызывать снижение производительности при доступе к памяти со второго узла vNUMA.
Поскольку SQL Server поддерживает NUMA, может ли он делать предположения о влиянии доступа к памяти между NUMA, которое может повлиять на производительность в этом сценарии (т. е. пытаться сохранить доступ на одном узле и избегать доступа между NUMA)?
Можно ли предпринять какие-либо шаги, чтобы убедиться, что память равномерно распределяется по узлам pNUMA?
Хост следующий:
- vSphere 6.7.0
- 2x Xeon Gold 5217 (8 ядер)
- Общий объем памяти 768 ГБ
ВМ выглядит следующим образом:
- 12x vCPU (3 ядра на сокет = 4 сокета)
- 320 ГБ ОЗУ
- Windows 2012 R2
- SQL Server 2016 Enterprise
EDIT: x-mem показывает следующее, что не совпадает сcoreinfo
xmem-win-x64.exe -j6 -s -R -l -f test.csv -n5
00 01
00 1.21124 1.18519
01 1.19831 1.18695