为什么DM多路径设备的等待时间比基础设备更长？

我们有一个基于CentOS 6.4的服务器连接到Hitachi HNAS 3080存储，并观察到内核以只读模式重新挂载了文件系统：

5月16日07:31:03 GNS3-SRV-CMP-001内核：[1259725.675814] EXT3-fs（dm-1）：错误：重新挂载文件系统为只读

这发生在几个I / O错误之后，并且据报道该设备的所有路径都中断了：

5月16日07:31:03 GNS3-SRV-CMP-001多路径：mpatha：剩余活动路径：0

我一直在查看sar日志，可以看到很少的很大的等待时间（2秒）：

07:40:00       dev8-0     17.91    112.04     98.03     11.73      0.00      0.20      0.07      0.12
07:40:00      dev8-16      0.23      1.85      0.00      8.00      0.00      3.71      3.71      0.09
07:40:00      dev8-32     91.50   8338.76   5292.93    148.98      8.38     91.60      9.76     89.35
07:40:00     dev252-0     91.27   8336.91   5292.93    149.34     17.79    194.88      9.79     89.38
07:40:00     dev252-1    674.80   8168.16   5292.93     19.95   1473.53   2183.60      1.32     88.98

07：30：00-07：40：00之间的持续时间确实发生在文件系统以只读方式挂载的时间。但是，即使在正常条件下，一个反复观察到的结果是，底层设备的等待时间比多路径设备的等待时间低得多。例如：

00:00:00          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
00:10:00       dev8-0     19.27    129.41     78.61     10.80      0.01      0.27      0.16      0.32
00:10:00      dev8-16      0.23      1.80      0.00      8.00      0.00      0.86      0.84      0.02
00:10:00      dev8-32     94.88  10285.16   3363.48    143.86      3.39     35.76      6.83     64.82
00:10:00     dev252-0     94.65  10283.34   3363.48    144.18      3.64     38.47      6.86     64.89
00:10:00     dev252-1    435.06  10087.12   3363.48     30.92    118.42    272.21      1.47     64.12

dev8-0恰好是本地磁盘，而dev8-16（/dev/sdb）和dev8-32（/dev/sdc）是dev252-0（）的基础磁盘/dev/mapper/mpatha。dev252-1（/dev/mapper/mpathap1）是一个跨越整个多路径设备的单个分区。这是来自的输出multipath -ll：

mpatha (2521501cbffffffffe96773b50ec30020) dm-0 BlueArc,NAS Platform
size=10T features='0' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=1 status=enabled
| `- 9:0:0:0 sdc 8:32 active ready running
`-+- policy='round-robin 0' prio=1 status=active
  `- 8:0:0:0 sdb 8:16 active ready running

为什么等待时间/dev/mapper/mpathap1要比/dev/mapper/mpatha甚至甚至/dev/sdb更长/dev/sdc呢？

performance iowait device-mapper

— pdp
source

似乎值得注意的是，从/dev/mapper/mpathap1到的过程中显然发生了很多请求合并/dev/mapper/mpatha。这也是大多数情况下await似乎要添加的层。您能否检查/sys/block/mpathap1/queue/scheduler和中使用了哪些电梯/sys/block/mpatha/queue/scheduler，可能将其切换到deadline或noop进行比较？

— 2015年

的I / O调度用于mpatha（/sys/block/dm-0/queue/scheduler）是noop和对于mpathap1（/sys/block/dm-1/queue/scheduler）是none。

— pdp

我强烈怀疑调度程序的排队/合并算法是造成延迟的原因。我会将基础设备的cfq交换为noop或截止日期，以查看其是否发生了任何变化。不过，这可能与您遇到的所有问题无关。

— 2015年

FWIW，我在其他类型的设备映射器设备（尤其是NSS池）上观察到了相同的行为。设备上的可合并写入确实dm比底层物理设备上具有更高的等待时间（和更长的队列），而未完成任何合并的读取请求和写入基本上不受影响。我还不知道这仅仅是由于等待方式的计算而导致的表示错误，还是由于排队/合并算法的性质而导致响应时间延长。

— 2015年

其中的SystemTap的IO脚本可能可能提供给您更深入地了解正在发生的事情。io_submit.stp，ioblktime.stp和biolatency-nd.stp可能是不错的起点。

— 卡桑德里2015年

正如用户所建议的那样，正在进行请求合并。您可以在avgrq-sz列中看到平均请求大小-显着增加。

现在，“等待”是在队列中花费的时间加上为这些请求提供服务所花费的时间。如果将一个小的请求（称为“ x”）与其他几个请求（y和z，在x之后发出）合并，则x将

在队列中等待与y合并
在队列中等待与z合并
等待（x，y，z）完成

显然，这将对等待统计产生负面影响，主要是因为计算等待的方式本身并没有实际表明问题。

现在，让我们看一下/ dev / sdb（dev8-16）。您知道您没有使用该路径吗？您的多路径配置中有两个优先级组，一个是

状态=启用

然后是

状态=有效

你可能有

path_grouping_policy故障转移

在您的配置中（这是默认设置）。

如果要防止两条路径都断开的IO错误，可以尝试：

        具有“ 1 queue_if_no_path”

在您的multipath.conf中

现在真正的问题仍然存在，为什么两条路径都走下去？

— 遥远的心灵
source