VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Часть 2.

Первую статью в новом 2018 году начну с продолжения рассмотрения NUMA.
В прошлой статье VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Оптимальное число VPD я рассматривал тяжелые условия работы виртуальных машин. Одним из показателей «тяжелости» — это количество свободной памяти в NUMA узле. Проводя множество экспериментов, я пришел к выводу, что имеется своеобразный порог свободного объема на NUMA узле: 12-15 Гб. Причем этот порог не жесткий. Рассмотрим как этот порог возникает.

Выделим VM-CLI-3 ВМ 100 Гб оперативной памяти (с помощью утилиты TestLimit). При размере NUMA узла 132000 Мб, даже при наличии свободной памяти в той же ноде NUMA, где размещена ВМ, часть памяти сразу уходит в удаленную. Уже затем балансировщик начинает переносить удаленную память «на родину». Если сочтет нужным.

В данном конкретном случае при наличии 12544 Мб 7278 Мб ушло в удаленную. Через 15 минут ситуация не изменяется. Т.е. в данном случае балансировщик не считает нужным реагировать. Возможная причина — мало ВМ на хосте, невысокая нагрузка. По крайней мере других объяснений у меня нет. Какой-либо иной закономерности я не выявил.
Включаем wide VM (VM-CLI) в конфигурации «4 по 6».

В верхнем левом углу видим время (прошло 20 минут) Все ушло в 1 ноду. VM-CLI-3 начала балансировать. За 20 минут 2%. При этом производительность у VM-CLI 50% (округленно). Что неудивительно, поскольку соотношение памяти между нодами — 16220 и 0 (вся память в ноде 0).  В 11.42, т.е. через 1 час после включения VM-CLI ее соотношение памяти не изменилась. А балансировка VM-CLI-3 уже 98%. Но производительность у VM-CLI 50% по прежнему.

Примечание: Так-то под максимумом подразумевается 53 тысячи, и 24 тысячи — это не точно 50%.

Запустил стресс-тест (опять используется AIDA-64). Потребление памяти  у VM-CLI увеличилась — но львиная доля опять же ушла в ноду 0. Балансировщик отреагировал —  VM-CLI-3 «перевернулась», т.е. «родной» стала нода 0.

За десять минут уровень сбалансированности повысился до 90. Запустил стресс-тест.

У VM-CLI  уровень памяти в ноде 1 подрос до 2768, что помогло немного задействовать вторую NUMA — производительность подросла до 28000. Но после выключения теста производительность опять скатилась. Выключение и включение VM-CLI ситуацию не изменило. Несмотря на то, что распределение памяти — 16722 и 8418. Время — 12.14

В 13.25 балансировка 98%. И не изменяется.

Перезагрузил VM-CLI. Производительность не изменилась — 50%.

Запустил стресс-тест. Сразу после завершения производительность — 39000. Уровень сбалансированности у VM-CLI-3 уменьшилась до 94%. Память у VM-CLI выросла в обоих нодах.

Но после выключения стресс-теста производительность быстро проседает.

А вот цикл включение-выключение VM-CLI в этом случае уже роль играет — память раскидывается поровну, и производительность — 53000.

Через 20 минут ничего не изменяется, — VM-CLI-3 так и остается с уровнем 94.

Это лишь один из тестов.  Который, тем не менее показывает весьма своеобразное поведение балансировщика NUMA при пограничных значениях свободной памяти в узлах.

Итак, выводы.

1. Существует порог свободной памяти в узлах NUMA. В моем случае это 12 — 15 Гб. Когда ВМ, расположенной в одном NUMA узле выделить (нагрузить) большое количество памяти, то даже при наличии свободной памяти в той же ноде NUMA, где размещена ВМ, часть памяти сразу уходит в удаленную. И этот уровень не жесткий. Уже после выделения балансировщик начинает выравнивать ВМ.
2. От этого порога также и зависят конфигурации «4-по-6» и «6-по-4», т.е. 4 VPD и 6 VPD. Если в узлах NUMA свободной памяти больше чем 15 Гб, то при включении wide ВМ разницы между этими конфигурациями скорее всего не будет. Но вот если памяти на каком-то узле меньше, то в ряде случаев вся память ВМ с 6 VPD уходила только в один узел. Соответственно мы имели 50% деградацию. Причем память ВМ с 4 VPD в этих же случаях размещалась в двух нодах. Если же памяти совсем мало, и к тому же идет балансировка, то и ВМ с конфигурацией 4-по-6 также проседает в производительности. Что и подтвердилось в данном эксперименте.
3. Я наблюдал ситуацию, отличную от той, что произошла в данном эксперименте. Т.е. после завершения балансировки ВМ с большим использованием памяти балансировщик самостоятельно приступил к балансировке wide ВМ. А в некоторых случаях для начала балансировки необходимо было немного разгрузить хост ESXi, переместив одну из машин на другой узел.
4. Балансировщик ориентируется на степень нагрузки. Например в данном случае два последних скриншота показывают одинаковый уровень сбалансированности у VM-CLI-3. И в этом нет ничего удивительного. После первоочередного выделения памяти балансировщик пытается ее разместить в одном узле. А вот в дальнейшем выделенная память воспринимается балансировщиком как неактивная (поскольку память выделена синтетически — программой TestLimit), и он игнорирует ее разбалансированность.
5. Балансировщику необходимо время чтобы выправить распределение памяти. Поэтому если в 09.00 ожидается резкое увеличение нагрузки, то проверьте достаточно ли свободной памяти на нодах NUMA и примите необходимые меры, например синтезируйте нагрузку заранее.
6. Перезагрузка ВМ не «сбрасывает» распределение памяти по NUMA, — необходим цикл «выключение — включение».
7. И, наконец, самый главный вывод — избегайте создания ВМ с большим размером ОЗУ, даже если он умещается в одну ноду.
Не забывайте, что Виртуализация — это лишь средство. А цель — это Консолидация. Какой смысл размещать в виртуальной инфраструктуре сервис, если они постоянно потребляет существенную часть ресурсов. Другое дело если пиковая нагрузка возникает не часто, и в этом случае действительно проявляются все преимущества виртуализации. Но опять же не забывайте, что если нагрузка предсказуема, то ВМ не должна быть сконфигурированна по максимуму все время. Избегайте выделять память и процессор про запас.

Если же у вашего сервиса возникают временами пиковые нагрузки, то конфигурируя большую и/или wide ВМ пристально следите за ее работой в части отработки балансировщика NUMA.
К сожалению в Veeam этого сделать не получится.
На форуме Veeam в 2016 году был задан вопрос в части введения счетчика N%L: NUMA locality. Сотрудники обещали подумать…