我在 RAID 0 SSD 上运行 30 台虚拟机。
VM 工作负载是一个繁重的 Docker 环境（准确地说是 docker-compose，运行大约 40 个容器）。
CPU 平均负载和 RAM 使用率都在服务器上的舒适参数范围内。但是磁盘利用率非常大，并且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'/>
我的 VM 主机正在使用内核，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如果我有“备用” CPU 资源，我应该使用吗？
另外，具体跟我的主机的内核版本有关：
- 我是否应该升级到内核版本
3.17+ 才能访问blk-mq（阻止多队列）？ - 如果是这样，如何在我的 QEMU/KVM 设置/定义中启用此功能？
- 最适合使用的访客调度程序是什么
blk-mq- 是吗none？
我将尽快为这个问题颁发赏金。
=== 编辑 ===
iostat我在完成正常的工作量后更新了上面的输出- 我们在 RAID0 阵列（软件 RAID）中使用 4x 2TB Samsung PM883 SSD
- 下面添加了一些基准统计数据：
来自主机的 RAID0 阵列的 fio / ioping
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
来自主机的 RAID1 OS 阵列的 fio / ioping
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
vda来自虚拟机设备的 fio
Jobs: 1 (f=1): [m(1)] [100.0% done] [246.2MB/82458KB/0KB /s] [62.1K/20.7K/0 iops] [eta 00m:00s]
我尝试将每个虚拟机的最大读取速度调整为 2300/写入速度为 800 - 但出于某些奇怪的原因，这让情况变得更糟。我遇到了更多的超时和作业失败。
以下是 Grafana 在工作负载过程中的样子：
答案1
问题的根源可能在于您使用的是带有 SATA 接口的 SSD。SATA 只有一个命令队列，即 SATA 总线上的多个命令无法并行运行。SAS 对此进行了一点改进，但 NVMe 确实有了很大的改进，它有多达 64k 个独立队列。
增加 SATA 中的队列深度会增加单个操作的延迟（同时增加吞吐量）。这可能是您增加 VM IOPS 时发生的情况。
我不指望 SATA SSD 能带来巨大收益blk-mq。更多也是如此iothreads。它们无法解决 SATA 接口上的争用问题。
虽然这可能不是您想要的，但我想最好的选择是将硬件升级到基于 NVMe 的 SSD。调度程序调整无法绕过硬件限制。