vSphere network test - vmxnet3

Со мной и с вами поделились очень интересным исследованием.
Из переписки:
 
 
По следам вот этой дискуссии на Вареруссишгруппенфоруме - Агрегирование каналов на стороне гостевой ос.
Топикстартер интересовался толстым-толстым каналом "для виртуальной машины". По ходу дела выяснилось, что Team-vNIC на vSwitch`e SLA не отрабатывает (как это заявлено для Team-pNIC, т.е. физ.аплинков).
Сошлись на том, что можно использовать VMXNET3 и всё будет ОК.
А я вдруг подумал - а насколько ОК? Что он может, этот самый VMXNET3? И решил погонять эту тему на стенде... Итак...

Стенд:

хост Сферы - 2 x Xeon 5620, 32GB RAM, ESXi 4.1U1 standalone
VM`ки - пара 2008R2 EE SP1 (2 vCPU, 6GB vRAM) с VMXNET3-интерфейсом на каждой (c IP MTU=1500); vNIC`и подключены к vSwitch1 c MTU=1500 без физ.аплинков.

Методика:
Тестирование проводилось с помощью известной утилиты NTttcp (v.30) в 64-битном варианте (NTttcp_x64.exe).
Каждый тест запускался пятикратно, в зачёт шёл лучший результат.
 

Часть I.

1.

Сначала провёл тестирование, запуская утилиту с такими же параметрами, что и в большинстве опубликованных ранее в инете тестов:
ntttcpr -m 1,0,192.168.1.58 -a 4 -l 256K -n 100000 -f s.txt
Единственное, что позволил себе изменить - это на порядок увеличить к-во тестового траффика ("-n 100000"),
бо при "-n 10000" ("те" тесты делались на гигабите) тест проскакивал слишком быстро, а мне хотелось, чтобы трафф "устоялся".
Получил вот что:
================================================================================
Date: 3-20-2010
Time: 20:40:0
Parameters: Number_Of_Threads=1 Number_Of_Buffers=100000 Length_Of_Buffers=262144 IOs=4 Realtime=33.750
Network Characteristics I: Pkts/Intr=30 Total_Bytes=26214.2 Avg_Frame_Size=1460
Network Characteristics II: Pkts_Sent=766253 Pkts_Received=17954923 Rexmits=0 Errors=0
Throughput(Mbps)=6213.73 CPU=42.4% Cycles/Byte=2.62 Interrupts/Sec=17506
================================================================================
В дальнейшем, чтобы не загромождать отчёт, буду приводить только последнюю строчку - с собственно скоростью линка.

2.

Далее прогнал этот же тест, только с несколькими тредами ("-m 2, -m 4, -m 8"). Получил следующие результаты:
= ntttcpr -m 1(2,4,8),0,192.168.1.58 -a 4 -l 256K -n 100000 -f s.txt
======================== 1, 2, 4, 8 ============================================
Throughput(Mbps)=6213.73 CPU=42.4% Cycles/Byte=2.62 Interrupts/Sec=17506
Throughput(Mbps)=7515.01 CPU=44.1% Cycles/Byte=2.25 Interrupts/Sec=12579
Throughput(Mbps)=7983.15 CPU=45.5% Cycles/Byte=2.19 Interrupts/Sec=8685
Throughput(Mbps)=8256.33 CPU=47.9% Cycles/Byte=2.23 Interrupts/Sec=7318
===========================================================================
Первой строкой я повторил результат для одного треда - для наглядности.
Здесь видно, как растёт пропускаемый траффик - в восьмитредовом варианте он уже доходит до 1ГБайта/сек.
Одновременно растёт и загрузка процессора (CPU 0 - по условию теста) - почти 50% это суммарная для обоих vCPU, а применительно к vCPU 0 она доходит почти до 100%.
Отмечу, что это на стороне приёмника (на передатчике загрузка процессоров (суммарная) болтается в районе 10-11% (в интервале от 9 до 12)) - что и понятно, т.к. приёмнику приходится выполнять все "offload"-операции VMXNET3 силами собственного процессора.

3.

Вчитавшись как следует в документацию к утилите NTttcp, обнаружил там интересную рекомендацию - для тестирования 10-гигабитных линков использовать бОльшее к-во "received buffers" - а именно 16.
Повторил тест №2 (точно так же с 1,2,4 и 8 тредами) с пар-ром "-а 16":
= ntttcpr -m 1(2,4,8),0,192.168.1.58 -a 16 -l 256K -n 100000 -f s16.txt =
======================== 1, 2, 4, 8 === -a 16 ===================================
Throughput(Mbps)=6805.93 CPU=46.0% Cycles/Byte=2.60 Interrupts/Sec=27097
Throughput(Mbps)=7633.75 CPU=45.6% Cycles/Byte=2.29 Interrupts/Sec=14933
Throughput(Mbps)=8251.03 CPU=46.5% Cycles/Byte=2.16 Interrupts/Sec=9107
Throughput(Mbps)=8615.52 CPU=48.3% Cycles/Byte=2.15 Interrupts/Sec=6966
==========================================================================
Что тут сказать - видимо, иногда RTFM не роскошь, а средство передвижения (в сторону лучшей производительности, ага!)...:)

4

Все предыдущие тесты делались на одном vCPU 0 (включая и мультитредовые) - параметр "-m x,0,IP".
Тот же TFM на утилиту, в частности, говорит о возможности разделения тредов по нескольким ядрам - для этого нужно параметр "-m" прописать по-другому:
ntttcpr -m 1(2,4),0,IP 1(2,4),1,IP ... ...
Тогда на каждое ядро должно приходиться по 2(4,8) тредов:
= ntttcpr -m 1(2,4),0,192.168.1.58 1(2,4),1,192.168.1.58 -a 16 -l 256K -n 100000 -f s16m.txt =
======================== -, 2, 4, 8 === -a 16 === -m IP IP ======================
-
Throughput(Mbps)=7593.38 CPU=49.0% Cycles/Byte=2.48 Interrupts/Sec=15911
Throughput(Mbps)=8341.46 CPU=51.3% Cycles/Byte=2.36 Interrupts/Sec=10253
Throughput(Mbps)=8775.02 CPU=53.5% Cycles/Byte=2.34 Interrupts/Sec=7234
=======================================================================
М-да, разница не сказать чтоб очень разительная - один-полтора процента (и не ясно - то ли скудный прирост, то ли погрешность эксперимента).
Да и по таскменеджеру машины-приёмника видно было, что львиная доля нагрузки по-прежнему падает на vCPU 0 - нагрузка на vCPU 1 подросла, но не сильно.
На машине передатчике суммарная загрузка стала 12-13%, но "перекос" в сторону vCPU 0 по-прежнему никуда не делся.

5.

Строго говоря, "мультипроцессорное" распределение тредов в TFM`е к утилите предполагает использование не одного, а нескольких IP:
ntttcpr -m 1(2,4),0,IP1 1(2,4),1,IP2 ... ...
Присвоил VMXNET3-интерфейсам машин вторые IP-адреса (57 приёмнику и 59 передатчику) и повторил тест №4:
= ntttcpr -m 1(2,4),0,192.168.1.58 1(2,4),1,192.168.1.59 -a 16 -l 256K -n 100000 -f s16mm.txt =
======================== -, 2, 4, 8 === -a 16 === -m IP1 IP2 ====================
-
Throughput(Mbps)=7695.32 CPU=50.0% Cycles/Byte=2.49 Interrupts/Sec=15678
Throughput(Mbps)=8365.41 CPU=51.2% Cycles/Byte=2.35 Interrupts/Sec=9841
Throughput(Mbps)=8830.10 CPU=53.7% Cycles/Byte=2.34 Interrupts/Sec=7546
======================================================================
В общем, примерно то на то и выходит - в том числе и с загрузкой на vCPU приёмника и передатчика.
То ли я чего-то не понимаю в реализации multiprocessor-multithreding у данной утилиты, то ли в моём случае почти без разницы раскладка тредов по процессорам.
Собственно, первую часть тестирования на этом можно было бы и завершить, но я решил сделать сравнение – прогнать те же тесты на тех же виртуалках, но на другом железе: entry-level-хосте Сферы на C2Q Q9550 (4x2.83GHz) / 16GB RAM.
Остальные условия те же (включая отдельный vSwitch NETTEST без физ.аплинков).
Вначале повторил тест №3:
= ntttcpr -m 1(2,4,8),0,192.168.1.58 -a 16 -l 256K -n 100000 -f s16.txt =
======================== 1, 2, 4, 8 === -a 16 ===================================
Throughput(Mbps)=3388.43 CPU=43.7% Cycles/Byte=5.85 Interrupts/Sec=9172
Throughput(Mbps)=3717.48 CPU=47.5% Cycles/Byte=5.79 Interrupts/Sec=6746
Throughput(Mbps)=3702.41 CPU=49.0% Cycles/Byte=5.99 Interrupts/Sec=3960
Throughput(Mbps)=3566.10 CPU=49.7% Cycles/Byte=6.31 Interrupts/Sec=4913
==========================================================================
Сразу видно, насколько показатели скромнее предыдущих – десктопное железо даже при номинально большей частоте CPU проигрывает серверному.
Причём на четырёх тредах мы упёрлись (вышли на плато), а при восьми – даже слегка потеряли (на таск-менеджере у vCPU 0 в этом месте график загрузки практически слился с линией 100% - скрин я делать поленился, но и так ясно должно быть).
Похоже, много тредов весьма хорошо прогружают десктопный проц.
Для сравнения прогнал 4 и 8 тредов по-другому – с распределением по IP и vCPU (как в тесте №5):
= ntttcpr -m 2(4),0,192.168.1.58 2(4),1,192.168.1.59 -a 16 -l 256K -n 100000 -f s16mm.txt =
======================== -, -, 4, 8 === -a 16 === -m IP1 IP2 ====================
-
-
Throughput(Mbps)=3567.30 CPU=61.1% Cycles/Byte=7.77 Interrupts/Sec=4078
Throughput(Mbps)=3693.90 CPU=66.3% Cycles/Byte=8.13 Interrupts/Sec=3435
=====================================================================
Ясности это, правда, не прибавило, хотя этот тест я прогнал дважды (по пять итераций для каждого к-ва тредов, согласно условию). Решил для себя, что много тредов – это не для такого хоста… J
И промежуточный вывод по итогам первой части – всё-таки откровенно пренебрегать мощностью/производительностью аппаратной части не стОит: как мы видим, потребность в той же «процессорной дури» может быть весьма высокой.
Это я к тому, что на форуме и в блоге периодически встречаю высказывания о желании устроить (пусть даже и тестовый, но не только) хост Сферы на, стыдно сказать, «атомных» системах…

Часть II.

UPD. Новая часть 2 - vSphere network test - vmxnet3, Jumbo Frames

Во второй части тестирования я решил проверить влияние Jumbo Frame`ов на производительность сети – а конкретно в том же акцепте, что и в первой части, т.е. между двумя виртуалками на 10Gb-ном линке (между двумя VMXNET3).

Понятно, что для проверки нужно задать режим JF=ON (9000) на vNIC`ах VMXNET3 (в свойствах драйвера сетевого подключения АКА карты) и включить JF на тестовом vSwitch1 (NETTEST) командой esxcfg-vswitch –m 9000 vSwitch1.

(После этого можно ещё сравнить производительность при стандартном и увеличеннном IP MTU в виртуалках, но вначале, всё же, хотелось разобраться с JF).

ОК, JF включен и на vNIC`ах, и на vSwitch1, делаю проверку (как указано в Книге) с передатчика (1.58) на приёмник (1.56):

ping –f –l 8972 192.168.1.56

и получаю облом:

Packet needs to be fragmented but DF set

Пробую обратно - с 1.56 на 1.58 – то же самое.

Пробую без флага –f (без запрета фрагментации) – пинги проходят.

Т.е. большие (8972) ICMP-пакеты без фрагментации идти между виртуалками не хотят.

Переключаю обе тестовые виртуалки на vSwitch0 (VM Network) с аплинком и включаю JF на этом свитче. Пробую

ping –f –l 8972 192.168.1.56(58)

с физ.машины из этой же подсети (JF на pNIC`е этой физ.машины включен (9014).

Нефрагментированные большие пинги проходят от физ.машины до каждой из тестовых виртуалок.

Пробую пингануть обратно – из тестовой виртуалки физ.машину:

ping –f –l 8972 192.168.1.13

и опять получаю

Packet needs to be fragmented but DF set

Ещё раз делаю пинг с виртуалки на «физику», но уже без запрета фрагментации – всё прекрасно проходит.

По всему выходит так, что JF на Вирт.коммутаторе работают как-то криво – vSwitch пропускает без фрагментации пакеты, входящие в vSwitch из pNIC`ов и не пропускают входящие из vNIC`ов.

Беглая проверка показала, что на хосте ESXi 4.0U1 JF ведут себя абсолютно так же.

Лично у меня этому объяснения пока нет – констатирую голый факт.

Если кто-то сможет объяснить это явление – вэлкам! :)

* * *

Собственно после облома с JF тестирование было прекращено – ну какой интерес лупить большими фреймами, если они всё-равно будут фрагментированы.

Вот как-то так…
С уважением,
Umlyaut.