LINUX.ORG.RU

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

 , ,


1

9

Имеется система

# lscpu | grep 'Model name'
Model name:            AMD EPYC 7401 24-Core Processor
# lsb_release -d
Description:	Debian GNU/Linux 9.4 (stretch)
# uname -r
4.15.0-0.bpo.2-amd64
в ней LVM том, который подключен к виртуалке (там ядро 4.9 уже тоже 4.15) так:

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none' io='threads'/>
  <source dev='/dev/fast/data'/>
  <target dev='vdb' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</disk>

fio с конфигом

blocksize=4k
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
numjobs=32
выдаёт
3060 MB/s 800k IOPS на хосте
400 MB/s 100k IOPS в госте

Если я правильно интерпретировал информацию, выданную гуглом, то KVM умеет работать с одним диском только в один поток, что в данном случае и даёт столь большую разницу.

Собственно вопрос: есть ли способ заставить дисковую систему работать в виртуалке если не на полную катушку, то хоть на пол катушечки?

PS Пробовал подключать образы qcow2 и raw, играться с cache, io, iothreads разными способами без заметного результата.


Эт конечно печально, что по 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

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

router ★★★★★ ()

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

cyroot ()
Ответ на: комментарий от anonymous

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

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

cyroot ()
Ответ на: комментарий от rootmaster

Что с 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>

NeOlip ()
Ответ на: комментарий от anonymous

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

NeOlip ()

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

<controller type='scsi' index='0' model='virtio-scsi'>
<driver queues='$vcpu'>
</controller>
chaos_dremel ★★ ()
Ответ на: комментарий от chaos_dremel

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>
NeOlip ()
Последнее исправление: NeOlip (всего исправлений: 1)
Ответ на: комментарий от NeOlip

<driver queues='16' />

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

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

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

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

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, сейчас откровенно лень.

NeOlip ()
Ответ на: комментарий от dyasny

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

NeOlip ()
Ответ на: комментарий от NeOlip

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

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

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

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

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от NeOlip

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

darkenshvein ★★★★★ ()
Последнее исправление: darkenshvein (всего исправлений: 1)

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

muon ★★★ ()
Ответ на: комментарий от muon

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

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

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

NeOlip ()
Ответ на: комментарий от darkenshvein

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

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

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

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

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

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 2)
Ответ на: комментарий от NeOlip

При 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'ам физического диска ещё очень большой )

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от muon

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

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

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

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

NeOlip ()