DMマルチパスデバイスの待機時間が基礎となるデバイスよりも長いのはなぜですか？

Hitachi HNAS 3080ストレージに接続されたCentOS 6.4ベースのサーバーがあり、カーネルが読み取り専用モードでファイルシステムを再マウントするのを確認しました。

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の期間は、ファイルシステムが読み取り専用でマウントされたときに発生します。ただし、通常の状況下でも、繰り返される観察の1つは、基礎となるデバイスの待機時間がマルチパスデバイスの待機時間よりはるかに短いということです。例えば：

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
ソース

から/dev/mapper/mpathap1への途中でどうやら多くの要求マージが起こっていることは注目に値するよう/dev/mapper/mpathaです。これは、ほとんどのawait場合に追加されると思われるレイヤーでもあります。あなたはで使用されているエレベーター確認することができます/sys/block/mpathap1/queue/schedulerし、/sys/block/mpatha/queue/scheduler多分にそれを切り替え、deadlineまたはnoop比較のために？

— the-wabbit

I / Oスケジューラについてはmpatha（/sys/block/dm-0/queue/scheduler）であるnoopとのそれmpathap1（/sys/block/dm-1/queue/scheduler）ですnone。

— pdp

スケジューラのキューイング/マージアルゴリズムが遅延の原因であると強く疑います。基本的なデバイスのcfqを何も変更しないかどうかを確認するために、noopまたはdeadlineに交換します。ただし、これはすべてのパスダウンの問題とは無関係です。

— -wabbit

FWIW、他のタイプのデバイスマッパーデバイスで、特にNSSプールで同じ種類の動作を観察しました。マージ可能な書き込みはdm、基礎となる物理デバイスよりもデバイスでの待機（および長いキュー）が高くなりますが、マージが行われない読み取り要求と書き込みは主に影響を受けません。これは、待機の計算方法による単純な表示エラーなのか、キューイング/マージアルゴリズムの性質による実際の応答時間の延長なのか、まだわかりません。

— -wabbit

Systemtap IOスクリプトの 1つは、何が起こっているかについての追加の洞察を提供する可能性があります。io_submit.stp、ioblktime.stp、およびbiolatency-nd.stpは、開始するのに適した場所です。

— Kassandry

ユーザーthe-wabbitが示唆するように、リクエストのマージが進行中です。列avgrq-szで、平均リクエストサイズ-大幅な増加を示していることがわかります。

現在、「待機」とは、キューで費やされた時間に、それらのリクエストの処理に費やされた時間を加えたものです。小さなリクエスト（「x」と呼びましょう）が他のいくつかのリクエスト（yとz、xの後に発行される）とマージされる場合、xは

キューで待ち、yとマージされる
キューで待機し、zとマージされる
（x、y、z）が完了するまで待つ

これは明らかに、待機統計にマイナスの影響を及ぼしますが、これは主に、実際に問題を示すことなく、待機の計算方法が原因です。

ここで/ dev / sdb（dev8-16）を見てみましょう。そのパスを使用していないことをご存知ですか？マルチパス設定に2つの優先度グループがあり、1つは

status = enabled

そして

status = active

おそらく持っている

path_grouping_policyフェイルオーバー

構成（デフォルト）。

両方のパスがダウンしている場合にIOエラーを防ぐには、次を試してください。

        機能「1 queue_if_no_path」

multipath.confで

今、本当の疑問が残っています。なぜ両方のパスがダウンするのですか？

— 遠い心
ソース