Виртуализация VMware

VMware ESXi 6.0. Влияние балансировки NUMA на производительность. Оптимальное число VPD.

На тему NUMA в vmware написано относительно много статей, где даны рекомендации по конфигурированию виртуальной машины. В основном они касаются настройки процессора и даны соответствующие рекомендации. Однако когда я приступил к практическим тестам то выяснил, что не все так однозначно. Даже если все сделано согласно рекомендациям, и у вас достаточно свободных ресурсов (CPU, память), то производительность wide vm (виртуальная машина, которая выходит за пределы узла NUMA) может проседать. Виной тому – балансировка NUMA. Вернее – память, несбалансированная между NUMA-узлами. Да и прочитанные рекомендации по “ядро-на-сокет” тоже оказались не универсальными.
Сразу оговорюсь – по сути это не такая большая проблема, поскольку просадка производительности наблюдается лишь для приложений, которые умеют задействовать многопоточность. А вот например Corona Renderer не зависит от балансировки NUMA. Более того, тест, сделанный программой Corona 1.3 Benchmark не зависел также и от конфигурации “ядро-на-сокет”.
Данная статья написана для тех, кто знаком с технологией NUMA и знает правила конфигурования ВМ. Если кто-то не ориентируется в данной технологии, но ему все же интересны мои эксперименты с конфигурацией “двухпроцессорный сервер с 12 ядрами” то предварительно рекомендую прочитать соответствующие материалы, на некоторые приведены ссылки в низу моей статьи.
Итак, что пишет про балансировку сама VMware: The intelligent, adaptive NUMA scheduling and memory placement policies in ESXi can manage all virtual machines transparently, so that administrators don’t need to deal with the complexity of balancing virtual
machines between nodes by hand (Performance Best Practices for VMware vSphere® 6.0). Если по-русски, то: NUMA сама знает как балансировать виртуальные машины и размещать их память между узлами NUMA, вмешиваться не надо. На мой взгляд – нужно было добавить “в большинстве случаев”.

Итак, что же я выяснил экспериментальным путем.

Прежде всего – балансировка работает! В большинстве случаев. И она пытается разместить ВМ так, чтобы их память распределилась равномерно между нодами, притом действует она весьма активно. Также планировщик следит за соотношением локальной и удаленной памяти. Т.е. если ВМ по количеству процессоров не выходит за рамки одной ноды, то она старается чтобы вся память была локальной. Так вот основное наблюдение – производительность виртуальных машин на хосте ESXi может существенно зависеть от степени сбалансированности памяти.
И в зависимости от уровня сбалансированности я выделил три уровня конфигураций виртуальной машины:
1. Оптимальная
2. Не оптимальная
3. Не совсем оптимальная.
Оптимальная конфигурация обеспечивает максимальную производительность*. Но в тяжелых условиях, т.е. когда NUMA разбалансирована, идет активная балансировка и на одной из нод мало свободной памяти, даже ВМ с оптимальной конфигурацией проседает в производительности.
Не оптимальная – даже при полной сбалансированности, т.е. если на хосте всего одна ВМ, она демонстрирует около 50% производительности от максимума.
Не совсем оптимальная – в основном ВМ работает на 100% мощности, но при некоторых условиях (уровень сбалансированности, количество свободной памяти на нодах и т.д.)  в которых “оптимальная” дает 100%, “не совсем оптимальная” может деградировать до 50% (примерно).
*Под максимальной производительностью понимается значение в тесте “CPU PhotoWorxx”.
Критерий оптимальности – это число vNUMA (или VPD). Но обо всем по порядку.
Моя тестовая конфигурация – двухпроцессорный сервер c Intel Xeon E5-2695v2 2.40GHz с 12 ядрами на сокет, 256 Гб ОЗУ.
Т.е. физический узел NUMA – 12 CPU (24 vCPU) 128 Гб ОЗУ.
Программы, с помощью которых проводил тестирование:
AIDA 64. В ней много тестов процессора, но самый полезный – тест CPU PhotoWorxx.
Corona 1.3 Benchmark.

Почему самый полезный  – это тест CPU PhotoWorxx? А потому что как следует из описания CPU PhotoWorxx использует соответствующие расширения наборов команд x87, MMX, MMX+, 3DNow!, 3DNow!+, SSE, SSE2, SSSE3, SSE4.1, SSE4A, AVX, AVX2, и поддерживает NUMA, гиперпотоковость, мультипроцессоры (SMP) и многоядерность (CMP). Т.е. если что-то не так с NUMA, то он это покажет. А еще он выполняется не так быстро, т.е. его данные в какой-то мере усредненные.
Методика тестирования.
Прежде всего нам нужно видеть распределение памяти но узлам NUMA. В этом нам поможет esxtop.
1. Заходим на хост ESXi по SSH (например PuTTy)
2. Запускаем ESXTOP.
3. Для вывода статистики по памяти жмем  m.
4. Для изменения полей f.
5. Чтобы увидеть NUMA жмем g. Одновременно можно убрать другие поля (нажимая например на b, k, l, o) и вывести информацию только по ВМ (SHIFT-V).

1. NUMA – конфигурация NUMA. Первое значение означает количество памяти в NUMA узле, а второе, в скобочках – количество свободной памяти.
2. NHN – Номер NUMA узла
3. NMIG – Количество миграций виртуальной машины между NUMA узлами
4. NMREM – Количество удаленной памяти, используемой ВМ
5. NLMEM – Количество локальной памяти, используемой ВМ
6. N&L – Процентное соотношение между локальной и удаленной памятью
7. GST_ND(X ) – Количество выделенной памяти для ВМ на узле X
8. OVD_ND(X) – Количество памяти потраченной на накладные расходы на узле X.
9. MEMSZ – Объем сконфигурированной памяти ВМ. ВМ никогда не получит памяти более этого значения, а в большинстве случаев будет получать значительно меньше из за разделения страниц (page sharing), баллонного драйвера или свопа.
10. GRANT – Объем памяти, предоставленный ВМ. Память не предоставляется ВМ пока к ней не возникнет хотя бы одного обращения.

Примечание: количество миграций виртуальной машины между NUMA узлами отображается только несколько секунд.

На данном скриншоте видим как раз случай когда идет активная балансировка. Только что произошла миграция у ВМ с именем VCSA. Три ВМ разбалансированны – в графе N&L – (процентное соотношение между локальной и удаленной памятью) 18%, 33% и 45%. Еще одна – VM-CLI-3 почти сбалансирована, ее уровень 94%.

Также мы видим что у нас два узла NUMA (пункт 1) по 128 Гб (1310ХХ Мб), и в NODE 0 свободно лишь 15251 Мб. И виртуальные машины, память которых в данных момент активно балансируется, как раз расположены в NODE 0.
Смотрим по объему памяти у ВМ. VM-CLI-3 имеет 131073 Мб (128 Гб) сконфигурированной памяти (MEMSZ – пункт 9), при этом выделено – 110645 Мб (GRANT – пункт 10). При этом около 6000 Мб – это удаленная память, т.е. находится в NODE 1. Чем и обусловлено значение N&L – (процентное соотношение между локальной и удаленной памятью) 94%.
По VM-CLI: хотя она и показывает 100% в столбце N&L, но в данном случае это ничего не значит, поскольку ВМ расположена в двух нодах и вся память у нее локальная. Смотреть нужно на конкретные значения памяти в нодах: 9490 и 19679. В идеале значения должны быть более менее одинаковыми.

Итак подытожим. Несмотря на то, что на хосте свободно довольно много памяти (около 79000 Мб) виртуальные машины хоста работают в весьма тяжелых условиях.

Отсюда два вывода:
1. Лучше не создавать большие ВМ.
2. Если все же такая необходимость возникла, то необходимо как минимум знать конфигурацию NUMA. И желательно понимать как она работает.

Смоделировать такие тяжелые условия работы позволяет программа TestLimit, про которую я писал в прошлой статье Стресс тест ESXi (потребление памяти виртуальными машинами). Именно с ее помощью можно выделить (загрузить) внутри ВМ 110000 Мб ОЗУ.

Далее, что нам нужно, это знать конфигурацию vNUMA, т.е. как NUMA видит виртуальная машина.
1. Способ – утилита Coreinfo v3.31
Для запуска – запускаем командную строку, переходим в папку с программой, и вводим

coreinfo

Ключ -n позволяет вывести только краткое распределение процессоров по нодам.

2. Лог файл виртуальной машины. Есть команда, которая позволяет вытаскивать необходимые данные, но у меня она не сработала:

vmdumper -l | cut -d / -f 2-5 | while read path; do egrep -oi «DICT.*(displayname.*|numa.*|cores.*|vcpu.*|memsize.*|affinity.*)= .*|numa:.*|numaHost:.*» «/$path/vmware.log»; echo -e; done

Поэтому я отрывал лог файл. Опять же есть два способа.
Первый – скачать файл vmware.log из папки ВМ (при выключенной машине).
Второй – зайти непосредственно на хост через ESXi Embedded Host Clien (https://адрес/ui).

Во всех случаях мы видим 4 VPD по 6 процессоров, итого 24.
Т.е. 4 сокета по 6 ядер.

Внутри ОС

Ниже привожу таблицу с результатами тестов.
Некоторые значения округлены, некоторые тесты не проводил. Некоторые тесты напротив были проведены очень много раз (подряд, через интервалы времени, после выключения/перезагрузки).
Тесты чтения/записи памяти выполняются довольно быстро, поэтому у них и высокая погрешность.
Так сказать рабочая тетрадь.
Описание теста CPU PhotoWorxx я привел выше, описание остальных тестов процессора доступно на сайте AIDA64
Значения, которые приведены через “/” – это как раз случай, когда удалось воссоздать 50% просадку производительности у ВМ “не совсем оптимальной” конфигурации.

Конфигура-ция
 
VPD
 
CPU PhotoWorxx
 
CPU ZLib CPU AES
Чтение 
из памяти
Запись в память Копирование в памяти Corona 1.3
12 (12 по 1) 1 26300 456 16900       2100000
12 (6 по 2) 6 26800 461 16900       2159000
16 (16 по 1) 2 43000 609 21900       2700000
16 (8 по 2) 8 43000 608 22000       2700000
16 (2 по 8) 2 43000           2700000
20 (20 по 1) 2 48600 750 27000       3350000
20 (2 по 10)  2 49100 757 27300   3400000
20 (4 по 5)  4 48900 762 26700       3300000
20 (5 по 4) 5 23000 750 22400       3350000
24 (24 по 1)  2 53000 903 31600 94450 72000 82908  
24 (12 по 2)  2 53000 895 32000 94100 72000 83000  
24 (6 по 4)   6 53000/24500 900 31900 91660/47000 66200/27000 80400/36000 3980000
24 (4 по 6)  4 53100     95500 72000 83000 39940000
24 (3 по 8) 3 23600 898 28900 43000 23400 32500 39800000
24 (8 по 3) 8 53300            
25 (25 по 1) 3 23900            
32 (32 по 1) 3 23113            
32 (4 по 8) 4 51363     94765 72042   44820000
32 (8 по 4) 8 50666/23140            
36 (36 по 1) 3 22700 994 34870 48150 22380 30666  
36 (12 по 3) 12 50433 1044 34700 94500 59000 75000 46820000
36 (6 по 6) 6 49000 1053 35190 94019 66266 67600  
48 (48 по 1) 4 44700 1074 35800       4870000
48 (48 по 1)* 4 45200 1186 38180       5401300
48 (24 по 2)  24 35800 1168 37600 80570     5208000
48 (12 по 4) 12 46377 1152 38325 95882     5388130

Какие же общие выводы можно сделать из данной таблице?
1. Тест CPU PhotoWorxx показывает максимальную производительность (53000) при конфигурации с 24 vCPU. При дальнейшем увеличении количества vCPU значения в данном тесте снижаются.
2. Другие тесты процессора программы AIDA64, а также тест Corona 1.3 Benchmark растут с увеличением количества процессоров, но после 24 vCPU совершенно не пропорционально увеличению процессоров. Очень непропорционально.
3. При не оптимальной конфигурации просадка производительности в тесте CPU PhotoWorxx коррелируется с уменьшением скорости чтения/записи памяти.
4. ВМ с 48 vCPU тестировалась в двух режимах – когда она жила вместе с другими ВМ (не очень нагруженными) и после миграции остальных ВМ на другой хост. Производительность выросла. Но опять же не очень значительно.
5. Правило “одно ядро на один процессор” не универсально. Более того в некоторых случаях данная конфигурация показывала 50% просадку производительности по сравнению с многоядерной конфигурацией. В частности из таблицы видно, что при 32 и 36 vCPU в конфигурации одно ядро на сокет ESXi создает три VPD, что составляет не оптимальную конфигурацию.
6. Использованные тесты не показали разницу в производительности между одноядерной*  конфигурацией и многоядерной.
* – в случае если настройка “одно ядро на сокет” создает оптимальную конфигурацию.
Т.е. при 24 vCPU не обнаружилась разница между “1 ядро на сокет”, “12 по 2” и “4 по 6”.
7. Производительность зависит от числа виртуальных NUMA (VPD).

Оптимальное число VPD для 12-ядерного процессора.
VPD
 
Конфигурация*
 
1 оптимально
2 оптимально
4 оптимально
6 не совсем оптимально
8 не совсем оптимально
12 оптимально
24 не оптимально

* нечетные конфигурации не оптимальны по умолчанию.

P.S.
Данная статья описывает поведение балансировки NUMA в VMware ESXi 6.0.
В версии 6.5. количество виртуальных сокетов больше не равно количеству vNUMA узлов, о чем можно почитать в статье под номером 1.

Раз уж затронул версии ESXi, то упомяну, что с версии 6.0. добавленная память (по технологии Hot Add) балансируется между узлами NUMA.
Но вот горячее добавление CPU по прежнему не доступно. Т.е. установка соответствующей галочки отключает NUMA.

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

Статьи:

1. ОТВЯЗКА VNUMA ОТ КОЛИЧЕСТВА ЯДЕР В VSPHERE 6.5
(Перевод англоязычной статьи Френка Деннемана. Хоть название и про версию 6.5, но, тем не менее, в ней есть и теория про 6.0.)
2. NUMA для vCPU в vSphere 5
(перечень тонких настроек)
3. NUMA и что про него знает vSphere?
4.  Число ядер на виртуальный процессор виртуальной машины в VMware vSphere – производительность.
5. Оптимизация работы виртуальной инфраструктуры на базе VMWare vSphere
(подробное описание работы шедулера по размещению vCPU ВМ).
6. VMware VROOM! Blog

 

Related Post

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.