高IO待機-根本的な原因を特定する方法


10

2つの専用サーバーにMySQLインスタンスがあります。1つは本番用、もう1つはテストプラットフォーム用です。

2つのサーバーはかなり同じですが、唯一の違いはRAIDコントローラーと仮想ボリュームです(HDは同じです)。本番環境には、専用のHW RAIDコントローラとRAID 10ボリュームがあります。一方、RAIDコントローラはソフトウェア(Lenovo ThinkServer RAID 110i)のようで、ボリュームはRAID 5です。

MySQLのコミット中に、iowaitが高くなっていることに気付きました。

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8とdm-14-8はデータベースパーティションに関連しています。

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

RAIDコントローラーを疑っていますが、どうすれば確認できますか?


多分トピックから外れている:しかし、なぜデータベースでRAID5なのか?書き込みギャップによる悪い考え。HWとBBUはこれを多少緩和しますが、RAID 5は基本的に読み取りには適していますが、小さなトランザクションの書き込みには適していません。
Hennes、2015年

私には選択肢がなかったので... RAID 10はこのRAIDコントローラではサポートされていません(私のバージョンのRHELでは)
Bob Sauvage

@BobSauvageどんな進歩?
Huygens

明確にするために:io-waitには、マスストレージによって提供されないファイル記述子の待機も含まれますか?ソケットのように...
マッシモ

回答:


7

私の答えは2つの部分に分かれていました。ブロックデバイスドライバーの調査です。ユースケースで検討する価値のある最適化。しかし、データの損失につながる可能性があると報告されていたため、最後の部分を削除しました。コメントを参照してください。

ハードウェアの調査

同じアプリケーションですが、2つの異なるハードウェアセットではパフォーマンスが大きく異なるため、その理由を理解したいと思います。したがって、私はまず、「なぜ」の答えを見つけるのに役立つ手段を提案します。

パフォーマンスについては、Brendan GreggのブログでLinuxパフォーマンスマップをよく参照しています。低レベル(ハードウェアに最も近い)では、次のようなツールblktraceが最適であることがわかります。

このツールを本当に知らないので、私は周りを検索して、Marc Brookerによるblktraceに関するこの興味深い記事を見つけました。基本的には次のことを示唆しています。を使用してI / Oトレースを実行しblktraceます。bttツールを使用して、このトレースから情報を抽出します。これは次のようなものです(30秒のトレースの場合)。

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

出力はかなり長くなる可能性がありますが、D2Cエントリを探します。これにより、デバイスドライバーに配信されたI / Oが、このドライバーによって完了したと報告されるまでにかかる時間がわかります。

出力例(dnf upgrade私の忙しいラップトップのVirtualBox VMで実行中):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

最悪の場合、最大で3.94秒で、I / Oごとに平均45ミリ秒という残念な結果を示しています。

この調査を実行するためにblktraceを使用するその他の方法については、非常に有益なMarc Brookerの記事を参照してください。


innodbのパフォーマンスを改善するための回答の微調整で参照されているPerconaブログの投稿は、次のように更新されています。
vkats

@vkatsに感謝します。提案と記事を削除するために回答を更新しました。
Huygens

1

jbd2プロセスはext4ジャーナリング用です。mysqlのコミット中にファイルシステムがジャーナルに書き込む必要があることは論理的です。これが心配の理由ではありません。jbdによって引き起こされる負荷の量は、dm-10-8およびdm-14-8パーティションのマウントパラメーターの影響を受けます。何かが発生してサーバーが誤って再起動した場合にデータベースが破損しないようにするには、データベースパーティションで非常に保守的なジャーナリングを使用することが望ましいでしょう。比較のために、テスト環境で別のジャーナリングマウントオプションを選択できます。


私のjbd2 / dm-2-8は常にiotopで約8.5%のようですが、ディスクの読み取りがなく、ディスクへの合計書き込みが1時間で35MBであるため、問題はないと思います。ところで、ほとんどのDM-2(私はそれがあるから分からないこと-8。)でありは/ devで
アクエリアスパワー
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.