☰

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

tag-icon • tag-icon performance iowait device-mapper
为什么 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 multipathd：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？

答案1

正如用户 the-wabbit 所言，请求正在进行合并。您可以在 avgrq-sz 列中看到，平均请求大小显著增加。

现在，“await”是队列中花费的时间加上处理这些请求所花费的时间。如果一个小请求（我们称之为“x”）与其他几个请求（在 x 之后发出的 y 和 z）合并，那么 x 将

  • 等待与 y 合并
  • 等待与 z 合并的队列
  • 等待（x，y，z）完成

这显然会对 await 统计数据产生负面影响，主要是因为 await 的计算方式，而实际上并不表示存在问题。

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

状态=已启用

并且是

状态=活动

你可能已经

path_grouping_policy 故障转移

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

如果您想在两条路径都关闭的情况下防止出现 IO 错误，您可以尝试： 

        功能“1queue_if_no_path”
在你的 multipath.conf 中

现在真正的问题是，为什么这两条路都会失败？

相关内容