Оптимизация qemu / KVM для тяжелых рабочих нагрузок TPS и записи

Я использую 30 виртуальных машин на твердотельных накопителях RAID 0.

Рабочие нагрузки виртуальных машин представляют собой тяжелую среду Docker (если быть точным, docker-compose, около 40 контейнеров).

Средняя загрузка ЦП и использование ОЗУ находятся в пределах комфортных параметров на сервере. Однако использование диска очень велико, и iostat показывает, что показатели TPS и MB_wrtn - это то место, где выполняется работа:

Device:  tps       MB_read/s   MB_wrtn/s   MB_read   MB_wrtn
md5      2825.57   3.28        28.15       1673116   14379843

В настоящее время я определяю свои диски виртуальной машины следующим образом:

<driver name='qemu' type='raw' cache='none' io='threads'/>
<source file='os.img' aio='native'/>

Моя виртуальная машина использует ядро 3.10.0-1062.18.1.el7.x86_64 на CentOS Linux 7 (Core) и, как следствие, deadline планировщик. Гости используют гораздо более новое ядро и по умолчанию mq-deadline планировщик.

Я изо всех сил пытаюсь найти какую-либо реальную информацию об оптимизации и множество противоречивых советов о том, какие стратегии кеширования / io использовать.

Это действительно сложно измерить - самая тяжелая часть рабочей нагрузки может занять 2-3 часа, и только в течение примерно 30-минутного периода использование диска ухудшается - но это важная часть работы, и это вызывает большую медленность по сравнению с более низким использованием диска.

Поэтому мои вопросы:

Какая комбинация cache, io и aio предложит лучшую производительность при высокой рабочей нагрузке TPS / записи?
Должен ли я использовать iothreads при том, что у меня есть "запасной" ресурс процессора?

Кроме того, в частности, в отношении версии ядра моего хоста:

Стоит ли мне обновиться до версии ядра 3.17+ для доступа blk-mq (блокировать несколько очередей)?
Если да, как мне включить это в моих настройках / определениях QEMU / KVM?
Какой гостевой планировщик лучше всего использовать с blk-mq - это просто none?

Я назначу награду за этот вопрос, как только смогу.

=== РЕДАКТИРОВАТЬ ===

Я обновил iostat вывод выше после полной, обычной рабочей нагрузки
Мы используем 4 SSD Samsung PM883 емкостью 2 ТБ в массиве RAID0 (программный RAID)
Ниже добавлена некоторая контрольная статистика:

fio / ioping из массива RAID0 хоста

Jobs: 1 (f=1): [m(1)][100.0%][r=421MiB/s,w=139MiB/s][r=108k,w=35.7k IOPS][eta 00m:00s]
---
9 requests completed in 1.65 ms, 36 KiB read, 5.45 k iops, 21.3 MiB/s

fio / ioping из массива ОС RAID1 хоста

Jobs: 1 (f=1): [m(1)][100.0%][r=263MiB/s,w=86.7MiB/s][r=67.3k,w=22.2k IOPS][eta 00m:00s]
---
9 requests completed in 1.50 ms, 36 KiB read, 6.00 k iops, 23.5 MiB/s

fio с виртуальной машины vda устройство

Jobs: 1 (f=1): [m(1)] [100.0% done] [246.2MB/82458KB/0KB /s] [62.1K/20.7K/0 iops] [eta 00m:00s]

Я пробовал настроить каждую виртуальную машину на максимум 2300 операций чтения / записи в секунду, но по какой-то странной причине это значительно ухудшает ситуацию. Я сталкиваюсь с гораздо большим количеством тайм-аутов и сбоев в работе.

Вот как выглядит Grafana во время рабочей нагрузки:

Вероятно, корень проблемы в том, что у вас есть SSD с интерфейсом SATA. SATA имеет только одну очередь команд, то есть несколько команд на шине SATA не могут выполняться параллельно. SAS немного улучшает это, но на самом деле он стал намного лучше с NVMe, который имеет до 64 КБ независимых очередей.

Увеличение глубины очереди в SATA увеличивает задержку отдельных операций (при увеличении пропускной способности). Вероятно, это произошло, когда вы увеличили количество операций ввода-вывода виртуальной машины в секунду.

Я бы не ожидал огромного выигрыша от SATA SSD с blk-mq. То же самое и для большего iothreads. Они не могут обойти конфликт на интерфейсе SATA.

Хотя это, вероятно, не то, что вы ищете, я думаю, ваш лучший вариант - это обновление оборудования до твердотельных накопителей на базе NVMe. Настройка планировщика не может обойти аппаратные ограничения.