web-dev-qa-db-ja.com

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の期間は、ファイルシステムが読み取り専用でマウントされたときに発生します。ただし、通常の条件下でも、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の待機時間よりもはるかに長いのはなぜですか？

performanceiowaitdevice-mapper
20
pdp

ユーザー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」

今、本当の問題が残っています、なぜ両方の道が下がるのですか？

2
remote mind