Раньше уже проверяли производительность PostgreSQL в зависимости от числа ядер и встал вопрос, насколько влияет использование разных средств виртуализации на производительность.
Содержание
Тестовое окружение[править]
- 2 процессора Xeon E5-2690v2 (в каждом 10 ядер, 20 потоков). В сумме 20 ядер и 40 HT-потоков частотой 3 ГГц и 3.6 ГГц TurboBust;
- ОЗУ 128 ГБ;
- Дисковая система: RAID 10 из 4 SSD Intel SSD DC S3500 по 800ГБ на контроллере Adaptec 6805 (контроллер имеет производительность где-то на уровне 30-40 тыс. IOPS. Но в процессе тестирования в основном бенчмарк генерировал нагрузку в 2000 IOPS, т.е. сильно меньше потолка контроллера;
На этом сервере последовательно устанавливались и тестировались:
- Hyper-V в Windows Server 2012 (первое поколение ВМ) 2 ГБ vRAM;
- CentOS8 baremetal;
- KVM под управлением CentOS8 2 ГБ vRAM.
Методика тестирования[править]
Тест проводился с помощью sysbench на одиночном файле в 50ГБ с вариацией:
- числа потоков (--num-threads), коэффициента чтения к записям от 0.1 до 10 для случайного ввода-вывода;
- числа потоков (--threads) для последовательных чтения и записи.
Стоит отметить, что в некоторых случаях чтение фактически шло из ОЗУ, поэтому надо относится критично к показателям чтения.
Подготовка:
sysbench --file-total-size=50G --file-num=1 fileio prepare
Запуск производится похожей командой:
sysbench --file-total-size=50G --file-num=1 --file-test-mode=rndrw --time=100 --file-rw-ratio=X fileio run
Результаты[править]
Полные результаты здесь: https://elibsystem.ru/sites/default/files/user/ars/blog/performance/virtualization_sysbench/server_benchmark.ods
Последовательное чтение[править]
Видно, что baremetal читает из ОЗУ. Можно допустить, что VM тоже читают из ОЗУ (скорость в 2 ГБ/c являются характерными для такого чтения), просто память vRAM была выделена в 2ГБ и оказалась на одном канале.
Последовательная запись[править]
Случайные операции в один поток[править]
Случайные операции в 20 потоков[править]
Случайные операции в 38 потоков[править]
Обсуждение результатов[править]
Операции чтения идут из ОЗУ и неадекватно отражают производительность системы. ОЗУ на хосте 128 ГБ больше тестового размера файла в 50 ГБ.
По производительности Hyper-V и KVM часто близки, причем KVM быстрее на последовательных операциях и медленнее на случайных.
Производительность на железе (baremetal) часто заметно больше производительности в виртуальных средах, особенно при большом числе потоков. Скорость по всем основным операциям: IOPS, throuthput, latency.
З.Ы.[править]
В одной группе прозвучало заявление, что якобы отличие VM от Baremetal на уровне 1% и все что тут намерено не соответствует действительности, якобы потому, что все плохо настроено, диски IDE вместо SCSI и т.д.
Чтобы опровергнуть это заявление был проведен небольшой эксперимент и вот его детальное описание.
- ПК: Ryzen 3600, 32 ГБ ОЗУ PC3200, SSD Intel 660P 2TB, Win11 Pro, Hyper-V
- Виртуализация: Hyper-V
- Виртуальная машина в Hyper-V 1 поколения Windows 7 x86.
- К ВМ добавлено два контроллера IDE и SCSI и к ним предварительно выделенные (не динамические) диски на 11ГБ NTFS с размером кластера 4k.
Тестируем fio 3.33 случайной записью в файл 10ГБ по 4k с iodepth=1. Тестируем в хосте Win11 и в виртуальной машине с диском, подключенным по IDE и диском, подключенным по SCSI.
fio -name=test -direct=1 -runtime=30s -bs=4k -rw=randwrite -iodepth=1 -size=10G
Результаты avg IOPS iodepth=1:
- native: 25373
- vm ide: 7144
- vm scsi: 7966
Таким образом IDE медленнее, но всего на 10%, а падение производительности при использовании Hyper-V при таком профиле нагрузки составляет 70% (а не 1%, как утверждал оппонент).
Кто-то может возразить, что надо Hyper-V 2-го поколения, но на ВМ c Win10 x64 SCSI ничего принципиально не отличалось (по этому результаты не приводятся).
А если тоже самое повторить с iodepth=16, то падение производительности от виртуализации уже не 70%, а 30%
fio -name=test -direct=1 -runtime=30s -bs=4k -rw=randwrite -iodepth=16 -size=10G
Результаты avg IOPS iodepth=16:
- native: 31188
- vm ide: 21696
- vm scsi: 21552
