Производительность дисковой системы KVM

virtio не пробовал?

Вроде оно и используется

<target dev='vdb' bus='virtio'/>

Эт конечно печально, что по iops в 8 раз, но если посмотреть на задержку, то получится разница в 0.28 мс на операцию. Печально, но avg lat 0.32 мс более чем достойно

router@europe:~$ echo '32/(800*10^3)' | bc -l
.00004000000000000000
router@europe:~$ echo '32/(100*10^3)' | bc -l
.00032000000000000000

На всякий случай подпишусь на тему

Прокидывай pci.

Виртуалка планируется не одна, так что хотелось бы найти другой вариант.

Насколько я понимаю, каждая виртуалка - отдельный процесс. А с диском работает ОСь

Т.е. как раз с несколькими ВМ есть шанс выжать из диска всё

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

а как можно с диском работать не в один поток? он же один!

Так же как с процессором, который тоже «типа один хДДД)))00».

Я замечал падение производительности при использовании LVM. Попробуйте поэкспериментировать подключив устройство целиком, и как локальную папку. Ну и для максимального быстродействия только RAW

https://wiki.mikejung.biz/KVM_/_Xen#virtio-blk_iothreads_.28x-data-plane.29

тут много разных вариантов оптимизации расписано. несколько лет назад, я помню из одного гостя выжимали то ли миллион то ли полтора iops. попугаи конечно, но смотрится красиво

Пробовал RAW, QCOW2, монтирование директории с хоста, LVM: разницы практически нет.

А пробовали прокинуть всё устройство целиком?

Проброс устройства не устраивает. Выше уже предлагали.

Попробуйте

Попробуй. Будь уже как все не будь мудаком.

Попробуй изменить глубину очереди iodepth=64 numjobs=64

При iodepth=64 numjobs=64 те же 100k IOPS
При numjobs=16 поднимается до 150k

Будь уже как все не будь мудаком.

Всю жизнь старался «не быть как все», дождитесь пока вашими ценнейшими советами кто-то поинтересуется, иначе идите с ними в известном направлении!

Диски сторадж локальные или хранилка?

Локальные. Intel P3700 NVMe

в опциях для образа диска добавте cache=writeback оно намного быстрей для гостя и позволяет работать кэшированию на хосте

cache='writeback' io='threads'

https://communities.intel.com/thread/76405

Всю жизнь старался «не быть как все»

Главное юбку не надевай

Что с writeback, что с none ~150k IOPS в госте. На хосте 700k (количество потоков fio снизил до 16)

Сейчас конфиг fio имеет вид

blocksize=4k
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
numjobs=16

Конфиг диска:

<disk type='file' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native'/>
  <target dev='vdb' bus='virtio'/>
</disk>

Я в курсе, что каждая пузомерка выдаёт результат в своих сферических попугаях, именно по этому пузомерка используется одна и с одинаковым конфигом. Либо я вообще не понял, что вы хотите сказать.

Попробовать сделать так, как сказано в «Правильный ответ» пункт 3. Если это возможно.

Насколько я помню virtio само по себе быстро, но имеет кучу ограничений. SCSI с моделью SCSI-контроллера «virtio» даёт даже лучшую производительность + поддержку TRIM/discard + нормальное наименование устройств + поддержку scsi_mq из коробки на госте

<controller type='scsi' index='0' model='virtio-scsi'>
<driver queues='$vcpu'>
</controller>

Да тоже самое по производительности.

Ставь Vmware ESXi

virtio-scsi даже чуть медленнее получилось: 100k IOPS

Конфиг:

<disk type='file' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='native'/>
  <source file='/path/to/img'/>
  <target dev='vdb' bus='scsi'/>
  <address type='drive' controller='0' bus='0' target='1' unit='0'/>
</disk>
<controller type='scsi' index='0' model='virtio-scsi'>
  <driver queues='16' />
</controller>

спасибо за тест, кстати.

<driver queues='16' />

1) а повысить можно?

2) попробуй с тем же 16 дать нагрузку так, чтобы iodepth * numjobs не превышало 16. В выводе интересен НЕ IOPS, а avg lat

3) я тут внезапно подумал.. а на хост системе NVME же, так? У него низкие задержки и как следвтвие высокий iops за счёт, на минуточку, отказа от стандартного стека протоколов. Т.е. там, ЕМНИП, ни разу не скази, идут оптимизированные команды. Т.е. может от виртуалки нет смысла ждать огромных цифр именно потому, что в виртуалке с эмуляцией scsi их не будет по определению

Кстати, по ссылке которую привёл dyasny:

Performance listed from highest to lowest.

• NVMe passthrough
• vhost-scsi
• virtio-scsi

1) В принципе можно. Попробую.

2) при 32/16 (iodepth/numjobs): 132K IOPS, avg lat ~ 3500 usec. Но 99.99 персентиль - 44288

При 32/8: 187K IOPS, avg lat - 1500 usec, 99.99 - 7840

При 2/8: 100K IOPS, avg lat - 150 usec, 99.99 - 506

3) Хорошая мысль, спасибо. Это действительно объясняет разницу в скорости (по крайней мере я, в силу своего незнания, готов принять эту версию (= ), а т. к. производительности на виртуалку итак будет вполне достаточно, то можно и подзабить.

Может в следующий раз таки попробую NVMe passthrough, сейчас откровенно лень.

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

При 2/8: 100K IOPS, avg lat - 150 usec, 99.99 - 506

Т.е. в ВМ реально задержка достигала 0.15 мс. В заголовке 0.32 получилось тупо за счёт задарнной сверх максимума длины очереди запросов

Ну т.е. если получится поднять с 16 до 32 ( на сторне виртуального диска ВМ ), то и iops будут 200k вместо 100к, грубо говоря

Т.е. выше 0.15 мс вряд ли прыгнуть, но поднять IOPS'ы можно

либо без проброса устройства действительно нереально выжать из SSD больше.

А vhost-scsi? Если конечно поретя живой миграции не критична

да кстати, можно попробовать пробросить весь диск, «сырой». то есть исключить слой ФС, когда в ВМ отдаётся файл-диск. если выше ещё не советовали.

Да в общем-то он это и сделал - пробрасывается LVM LV

лвм это таки гоняние проца. тогда надо собирать лвм массив уже внутри виртуалки (если оно так не было, ленива читать тред).

vhost-scsi

<hostdev mode='subsystem' type='scsi_host'>
   <source protocol='vhost' wwpn='naa.5001405f37c1f3f7'/>
   <address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/>
</hostdev>

При 32/8: 150K IOPS, avg lat - 1838, 99.99 - 11072

Отдай виртуалке два диска, и на ней собери RAID0. Вариант не для продакшена, но попугаев иногда позволяет увеличить. Будешь знать, если дело в однопоточности.

Я тут за последние дни поначитался всякого и вроде во всех тестах всяческих редхатов и айбиэмов берут 4/8/16/32 раздела, прокидывают их все в виртуалки и снимают over9000 IOPS со всей этой радости.

В связи с чем вопрос: а как этим пользоваться в продакшене-то? Собирать в виртуалке RAID из 16 дисков (которые на самом деле разделы одного диска) - это же наркомания какая-то (= Попугаи сами по себе меня мало интересуют в общем-то.

PS Собрать рейд попробую для полноты картины.

лвм это таки гоняние проца

Кхм. Это не файл на ФС, а весьма тонкая прослойка вроде обычной партиции

У меня тесты fio показывали оверхед от lvm около 5 мкс ( 0.005 мс ). Для сравнения, у ТС сейчас avg lat 150 мкс ( 0.15 мс ). Т.е. оверхед от lvm меньше стандартной погрешности измерений

тогда надо собирать лвм массив уже внутри виртуалки

Массив? Ты точно понимаешь, о чём идёт речь? И я таки не вижу разницы в производительности между выдачей LV в ВМ или выдачей диска и созданием LV внутри ВМ

При 32/8: 150K IOPS, avg lat - 1838, 99.99 - 11072

Такие бешеные задержки говорят о том, что очередь запросов от fio больше ( существенно больше ) глубины очереди диска ( виртуального ). Выше уже видели, что норм 0.15 мс

Поставь очередь запросов ( iodepth * numjobs ) поменьше и постепенно увеличивай. Начиная с некоторого числа у тебя почти перестанет расти IOPS и резко начнёт расти avg lat. Это значит, что полностью забил глубину очереди диска

Вот там, где на графике почти одинаковый IOPS ( от request number ), смотри минимальный avg lat. Это задержки для текущей конфигурации твоей ВМ, и там же глубина очереди виртуального диска

Пока создаваемая нагрузка не превысит возможности физического NVME диска ( а она не превысит :) ), именно эта задержка и определяет максимальный IOPS в виртуалке при фиксированной ( текущей конфигурацией ) длине очереди

Т.е. тут можно пытаться найти вариант выдачи диска, для которого задержки поменьше, или повышать глубину очереди ( если это возможно. т.к. запас по iops'ам физического диска ещё очень большой )

Только сегодня руки вновь дошли до этой железки.

Попробовал RAID0 из 2 и 4 дисков (raw image). В обоих случаях fio показал ~1000 Mb/s и 250K IOPS, но с 4 дисками задержки заметно меньше.

Так же пробовал натравливать fio на разделы без рейда: разницы не увидел.

Ну и на этом заканчиваю экспериментировать. Всем отписавшимся в теме ещё раз спасибо за участие.