☰

读写进程数量对不同 virtio-scsi lun 的 io 性能的影响

tag-icon • tag-icon kvm-virtualization scsi virtio
读写进程数量对不同 virtio-scsi lun 的 io 性能的影响 
QEMU emulator version 2.9.0(qemu-kvm-ev-2.9.0-16.el7_4.11.1)
Linux 3.10.0-693.el7.x86_64

有两个 LUN 通过 virtio-scsi 连接（vcpu=1，virtio-scsi 控制器队列设置为 1）

首先：

仅 dd /dev/sde 设备，iops 为 6k。

第二：

fio(num_job=3) + /dev/sdc 并仍然 dd sde

运行良好，sde 的 iops 仍为 6k。

最终的：

只将 fio 的 num_job 增加到 4，

然后 sde 的 iops 下降到 34 !!!!????

我不知道为什么，有人可以给我一些建议吗？

第一次测试：

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
sde               0.00     0.00    0.00 6638.14     0.00    51.86    16.00     0.92    0.14    0.00    0.14   0.14  92.16

第二次测试：

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00   99.01   76.24     0.77     0.60    15.95    96.04  547.80  969.59    0.01   5.65  99.01
sde               0.00     0.00    0.00 6966.34     0.00    54.42    16.00     0.83    0.12    0.00    0.12   0.12  82.87

最后一个考试：

Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00  100.00  107.00     0.78     0.84    16.00   128.97  621.03 1280.22    4.97   4.83 100.00
sde               0.00     0.00    0.00   31.00     0.00     0.24    16.00     0.99   32.03    0.00   32.03  32.03  99.30

日：

while true;do dd if=/dev/zero of=./test bs=8K count=102400 oflag=direct;done

配置文件

[global]
    bs=8k
    ioengine=libaio
    #rw=randrw
    time_based
    runtime=7200
    direct=1
    group_reporting
    iodepth=32
    size=1G
    
    [file1]
    filename=/dev/sdc
    numjobs=3
    rw=randrw

答案1

  • 比较dd有点fio棘手...我建议不要这样做，除非你理解它们是如何fio发送ddI/O 的，以及所有相关的注意事项。例如，你是否知道存储堆栈中的各种东西（文件系统、设备本身）可能会针对发送零的情况进行优化（例如通过检测或压缩），因此你获得的速度与使用非零数据时的速度不同？
  • 您使用的是一个较小的区域。发送的数据太少是另一个基准测试陷阱，这意味着您的结果可能会因覆盖破坏较旧的运行中命令而严重失真，并且较早的命令最终可能会被优化掉。在这种情况下可能性较小（由于O_DIRECT正在使用），但这是另一个潜在的干扰。结果失真更多。
  • 无法判断/dev/sdc和是否/dev/sde实际上由同一文件系统内的文件/主机上同一磁盘的分区表示。如果是这样，那么它们都在竞争必须来自同一底层设备的 I/O...

由于磁盘特性和 CPU 可用性（这适用​​于主机和客户机），可以保持运行的 I/O 数量存在上限。尝试执行更多操作意味着您只会对 I/O 队列和/或 CPU 产生争用。fio在发送 I/O 方面相当高效，并且您的作业文件显示它被允许一次“排队”比dd可以的更多的 I/O（我是否提到过这很难进行比较dd？fio）。您没有显示完整的fio输出，因此我们缺少一些有用的额外数据...剩余了多少 CPU（客户机和主机）？主机上的 iostat 看起来怎么样？如果存在争用，那么我预计甚至一 fio击败dd（使用您使用的设置）更不用说三个......

注意：如果由于某种原因你的磁盘队列绑定到特定的 CPU，那么你可能会遇到需要 CPU 开启的情况特别的处理器可用，并且如果两个磁盘都依赖于同一个磁盘...

相关内容