为什么DM多path设备的等待时间比底层设备高?

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

5月16日07:31:03 GNS3-SRV-CMP-001内核:[1259725.675814] EXT3-fs(dm-1):错误:重新装入文件系统只读

这发生在几个I / O错误之后,据说所有到设备的path都在下降:

May 16 07:31:03 GNS3-SRV-CMP-001 multipathd:mpatha:剩余活动path:0

我一直在看萨尔日志,可以看到几个非常大的(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之间的时间确实发生在文件系统以只读方式挂载的时候。 然而,即使在正常情况下,一个重复的观察是基础设备的等待时间比多path设备的等待时间低得多。 例如:

 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 )是跨越整个多path设备的单个分区。 这里是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的等待时间要高得多?

正如用户所指出的那样,请求合并正在进行。 您可以在avgrq-sz列中看到平均请求大小 – 显示了大幅增加。

现在“等待”是在队列中花费的时间加上为这些请求提供服务的时间。 如果一个小的请求,我们称之为“x”,与其他一些请求合并(y和z,在x之后发布),那么x将会

  • 在队列中等待与y合并
  • 在队列中等待tu与z合并
  • 等待(x,y,z)完成

这显然会对等待统计造成负面影响,主要是因为等待计算的方式,实际上本身并没有表明问题。

现在我们来看看/ dev / sdb(dev8-16)。 你知道你没有使用这条路吗? 您的多pathconfiguration中有两个优先级组,一个是

 状态=启用 

并且是

 状态=活性 

你可能有

  path_grouping_policy故障转移 

在你的configuration中(这是默认的)。

如果你想在两个path都closures的情况下防止IO错误,你可以尝试:

 function“1 queue_if_no_path” 

在你的multipath.conf中

现在真正的问题仍然存在,为什么两条路都走下坡路?