奇妙な繰り返しの過剰なI / O待機
このサイトでI/O待機について何度も議論されていることはよく知っていますが、他のすべてのトピックはconstant I/Oレイテンシーをカバーしているようですが、I/O問題は解決する必要があります私たちのサーバーは不規則な（短い）間隔で発生しますが、最大2万ミリ秒の待機時間と2秒のサービス時間の大規模なスパイクが常に存在します。影響を受けるディスクは/ dev/sdbです（詳細については、Seagate Barracudaを参照してください）。
典型的なiostat-xの出力は、次のようになることがあります。これは極端なサンプルですが、決して珍しいことではありません。
iostat (Oct 6, 2013)
tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
16.00 0.00 156.00 9.75 21.89 288.12 36.00 57.60
5.50 0.00 44.00 8.00 48.79 2194.18 181.82 100.00
2.00 0.00 16.00 8.00 46.49 3397.00 500.00 100.00
4.50 0.00 40.00 8.89 43.73 5581.78 222.22 100.00
14.50 0.00 148.00 10.21 13.76 5909.24 68.97 100.00
1.50 0.00 12.00 8.00 8.57 7150.67 666.67 100.00
0.50 0.00 4.00 8.00 6.31 10168.00 2000.00 100.00
2.00 0.00 16.00 8.00 5.27 11001.00 500.00 100.00
0.50 0.00 4.00 8.00 2.96 17080.00 2000.00 100.00
34.00 0.00 1324.00 9.88 1.32 137.84 4.45 59.60
0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
22.00 44.00 204.00 11.27 0.01 0.27 0.27 0.60
ハードウェアに関するもう少し情報を提供させてください。これは、OSとしてDebianを備えたDell 1950 IIIボックスであり、uname-aは次のように報告します。
Linux xx 2.6.32-5-AMD64 #1 SMP Fri Feb 15 15:39:52 UTC 2013 x86_64 GNU/Linux
このマシンは、データベースやI/Oの重いアプリケーションを実行せずにオンラインゲームをホストする専用サーバーです。コアアプリケーションは8GバイトのRAMのうち約0.8を消費し、平均CPU負荷は比較的低くなっています。ただし、ゲーム自体はI/O遅延に対してかなり敏感に反応するため、プレーヤーはゲーム内で大きなラグを経験します。これについては、できるだけ早く対処したいと思います。
iostat:
avg-cpu: %user %Nice %system %iowait %steal %idle
1.77 0.01 1.05 1.59 0.00 95.58
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sdb 13.16 25.42 135.12 504701011 2682640656
sda 1.52 0.74 20.63 14644533 409684488
稼働時間は次のとおりです。
19:26:26 up 229 days, 17:26, 4 users, load average: 0.36, 0.37, 0.32
ハードディスクコントローラー：
01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS 1078 (rev 04)
ハードディスク：
Array 1, RAID-1, 2x Seagate Cheetah 15K.5 73 GB SAS
Array 2, RAID-1, 2x Seagate ST3500620SS Barracuda ES.2 500GB 16MB 7200RPM SAS
Dfからのパーティション情報：
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sdb1 480191156 30715200 425083668 7% /home
/dev/sda2 7692908 437436 6864692 6% /
/dev/sda5 15377820 1398916 13197748 10% /usr
/dev/sda6 39159724 19158340 18012140 52% /var
Iostat -dx sdb 1で生成されたいくつかのデータサンプル（2013年10月11日）
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 15.00 0.00 70.00 0.00 656.00 9.37 4.50 1.83 4.80 33.60
sdb 0.00 0.00 0.00 2.00 0.00 16.00 8.00 12.00 836.00 500.00 100.00
sdb 0.00 0.00 0.00 3.00 0.00 32.00 10.67 9.96 1990.67 333.33 100.00
sdb 0.00 0.00 0.00 4.00 0.00 40.00 10.00 6.96 3075.00 250.00 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.00 0.00 0.00 100.00
sdb 0.00 0.00 0.00 2.00 0.00 16.00 8.00 2.62 4648.00 500.00 100.00
sdb 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 100.00
sdb 0.00 0.00 0.00 1.00 0.00 16.00 16.00 1.69 7024.00 1000.00 100.00
sdb 0.00 74.00 0.00 124.00 0.00 1584.00 12.77 1.09 67.94 6.94 86.00
Rrdtoolで生成された特性チャートはここにあります：
iostatプロット1、24分間隔： http://imageshack.us/photo/my-images/600/yqm3.png/
iostatプロット2、120分間隔： http://imageshack.us/photo/my-images/407/griw.png/
5.5 Gバイトのかなり大きなキャッシュがあるため、I/O待機スパイクがキャッシュミスイベントによって引き起こされる可能性があるかどうかをテストすることをお勧めします。したがって、同期を実行してから、これを実行してキャッシュとバッファをフラッシュしました。
echo 3 > /proc/sys/vm/drop_caches
その直後、I/O待機時間とサービス時間は事実上屋根を通り抜け、マシン上のすべてがスローモーションのように感じられました。次の数時間でレイテンシーは回復し、すべてが以前と同じようになりました。予測できない短い間隔で小から中程度のラグが発生しました。
今私の質問は：誰かがこの迷惑な行動を引き起こす可能性のあるものを知っていますか？これは、ディスクアレイまたはレイドコントローラーが停止していることを示す最初の兆候ですか、それとも再起動することで簡単に修正できるものですか？ （ただし、現時点では、ディスクが再び起動しない可能性があるため、これを行うことには非常に消極的です。）
どんな助けでも大歓迎です。
よろしくお願いします、クリス。
追加のために編集：1つまたは2つのプロセスが一番上に「D」状態になるのがわかります。そのうちの1つはかなり頻繁にkjournaldされているようです。しかし、私が間違っていなければ、これはプロセスを示しているのではなく、プロセス原因レイテンシーではなく、影響を受けたそれによって-間違っている場合は修正してください。中断できないスリーププロセスに関する情報は、問題に対処するのに何らかの形で役立ちますか？
@Andy Shinnがsmartctlデータを要求しました、ここにあります：
smartctl -a -d megaraid,2 /dev/sdb収量：
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST3500620SS Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:13 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
Current Drive Temperature: 20 C
Drive Trip Temperature: 68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 1236631092
Blocks received from initiator = 1097862364
Blocks read from cache and sent to initiator = 1383620256
Number of read and write commands whose size <= segment size = 531295338
Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 36556.93
number of minutes until next internal SMART test = 32
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 509271032 47 0 509271079 509271079 20981.423 0
write: 0 0 0 0 0 5022.039 0
verify: 1870931090 196 0 1870931286 1870931286 100558.708 0
Non-medium error count: 0
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 36538 - [- - -]
# 2 Background short Completed 16 36514 - [- - -]
# 3 Background short Completed 16 36490 - [- - -]
# 4 Background short Completed 16 36466 - [- - -]
# 5 Background short Completed 16 36442 - [- - -]
# 6 Background long Completed 16 36420 - [- - -]
# 7 Background short Completed 16 36394 - [- - -]
# 8 Background short Completed 16 36370 - [- - -]
# 9 Background long Completed 16 36364 - [- - -]
#10 Background short Completed 16 36361 - [- - -]
#11 Background long Completed 16 2 - [- - -]
#12 Background short Completed 16 0 - [- - -]
Long (extended) Self Test duration: 6798 seconds [113.3 minutes]
smartctl -a -d megaraid,3 /dev/sdb収量：
smartctl 5.40 2010-07-12 r3124 [x86_64-unknown-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net
Device: SEAGATE ST3500620SS Version: MS05
Serial number:
Device type: disk
Transport protocol: SAS
Local Time is: Mon Oct 14 20:37:26 2013 CEST
Device supports SMART and is Enabled
Temperature Warning Disabled or Not Supported
SMART Health Status: OK
Current Drive Temperature: 19 C
Drive Trip Temperature: 68 C
Elements in grown defect list: 0
Vendor (Seagate) cache information
Blocks sent to initiator = 288745640
Blocks received from initiator = 1097848399
Blocks read from cache and sent to initiator = 1304149705
Number of read and write commands whose size <= segment size = 527414694
Number of read and write commands whose size > segment size = 51986460
Vendor (Seagate/Hitachi) factory information
number of hours powered up = 36596.83
number of minutes until next internal SMART test = 28
Error counter log:
Errors Corrected by Total Correction Gigabytes Total
ECC rereads/ errors algorithm processed uncorrected
fast | delayed rewrites corrected invocations [10^9 bytes] errors
read: 610862490 44 0 610862534 610862534 20470.133 0
write: 0 0 0 0 0 5022.480 0
verify: 2861227413 203 0 2861227616 2861227616 100872.443 0
Non-medium error count: 1
SMART Self-test log
Num Test Status segment LifeTime LBA_first_err [SK ASC ASQ]
Description number (hours)
# 1 Background short Completed 16 36580 - [- - -]
# 2 Background short Completed 16 36556 - [- - -]
# 3 Background short Completed 16 36532 - [- - -]
# 4 Background short Completed 16 36508 - [- - -]
# 5 Background short Completed 16 36484 - [- - -]
# 6 Background long Completed 16 36462 - [- - -]
# 7 Background short Completed 16 36436 - [- - -]
# 8 Background short Completed 16 36412 - [- - -]
# 9 Background long Completed 16 36404 - [- - -]
#10 Background short Completed 16 36401 - [- - -]
#11 Background long Completed 16 2 - [- - -]
#12 Background short Completed 16 0 - [- - -]
Long (extended) Self Test duration: 6798 seconds [113.3 minutes]
（たとえば、ディスクはNFS経由ではなく、サーバーに直接接続されていると思います。）
重要なのは、svctm（iostat出力内）が非常にであることです。 ）高。これは、RAIDまたはディスクのハードウェアの問題を示唆しています。Svctm通常のディスクの場合は約4（ms）である必要があります。少ないかもしれませんが、高すぎないでください。
残念ながら、smartctlの出力はあなたの場合には有益ではありません。エラーは修正されていますが、これは正常である可能性があります。長いテストは正常に完了したようですが、これも決定的ではありません。 ST3500620SSは古き良きサーバー/ RAIDタイプのディスクのようです。これは（デスクトップ/非RAIDディスクとは異なり）読み取りエラーに迅速に応答するはずなので、これは不良セクタよりも複雑なハードウェアの問題になる可能性があります。 RAID統計で異常なもの（高いエラー率など）を見つけてみてください： http://hwraid.le-vert.net/wiki/LSIMegaRAIDSAS
私の提案は、ディスクの交換が次のステップであるべきだということです。
更新：
Svctmは、より重要な要素です。高いutil％はresultofsvctmが異常に高い。
desktopディスクがPromiseRAIDにインストールされたときに、同様の問題が発生しました。多くの長い再試行によって読み取りエラーを修復しようとするように設計されたデスクトップディスク。これは遅延の原因になります（これらの読み取りエラーは、vibrationなどの他の要因が原因である可能性があります。デスクトップよりもサーバールームの方がはるかに強力です）。それとは異なり、RAIDで使用するように設計されたディスクは、エラーをRAIDコントローラーにすばやく報告するだけで、RAID冗長性を使用してエラーを修正できます。さらに、サーバーディスクは、一定の強い振動に対してより機械的に耐性があるように設計できます。サーバーディスクはデスクトップと同じであるという一般的な神話がありますが、それは間違っています。実際にはareは異なります。
Q：ああ、私が聞きたかったこと：それがハードウェアの問題である場合、問題は継続的に表示され、しばらくの間消えないようにする必要があると思いませんか？その効果について何か説明がありますか？
A：
- 問題は常に存在する可能性がありますが、高負荷の場合にのみnoticeableになります。
- 振動レベルは、時間帯によって異なる可能性があります（たとえば、近くのサーバーの動作によって異なります）。あなたの問題が振動の影響を受けているディスクである場合、それは間違いなく消えて再び現れる可能性があります。 「デスクトップディスク」の問題が発生したときにも、同様の動作が見られました。 （もちろん、ディスクはサーバーのものであり、RAIDに推奨されるため、まったく同じ問題ではありません。ただし、類似している可能性があります。）
私は非常によく似た問題を抱えていました。 IBM ServeRaid M5110（LSI 9265-8iのブランド名を変更）およびCentOS 6.x
最初のVDは、IBMブランドの4台のHitachiドライブのRAID0でした。
次に、Samsung PM853T SSDを購入し、それらを別の4つのドライブにインストールして、別のRAID0を作成しました。ワークロードをプラッターからSSDに切り替えると、1時間ごとにIOが急上昇し、すべての操作が停止します。負荷は通常の約2から最大80になります。数十秒後、すべてが落ち着き、アプリケーションは引き続き機能します。
このような状況は、プラッターでは発生しませんでした。
だから、私の第一印象は、LSIとSamsungの間のある種の非互換性でした。数日後、頭を悩ませたりデバッグしたりした後、MegaCli64が原因であることがわかりました。ドライブの状態を監視するためにZabbix経由で実行しますが、コントローラーをスキャンすると、MegaCliはSSDでの待機を停止し、SSDごとに数十秒プラス4をほぼ2分実行します。これにより、すべてのI/Oがゼロになり、iowaitとロードが急増します。
解決策は、問題を引き起こさなかったMegaCliバージョンを見つけることでした。 IBMサイトからバージョンをダウンロードしました。