☰

Percona で 99% のディスク IO が急増

tag-icon • tag-icon linux mysql hard-drive io percona
Percona で 99% のディスク IO が急増

ディスク I/O がランダムに急上昇するサーバーがあり、ランダムな時間に 99.x% まで上昇し、明らかな理由もなくしばらく高い状態が続いた後、再び低下します。以前は問題にはなりませんでしたが、最近はディスク I/O が長時間にわたって 99% のままで、場合によっては 16 時間も続くことがあります。

サーバーは専用サーバーで、CPU コアが 4 個、RAM が 4 GB あります。Ubuntu Server 14.04.2 と percona-server 5.6 を実行しており、他に大きな問題は発生していません。ダウンタイムが監視されており、当社が扱うサーバーの CPU/RAM/ディスク I/O を常時表示する画面があります。サーバーは定期的にパッチ適用され、メンテナンスも行われています。

このサーバーはレプリカ チェーンの 3 番目であり、フェイルオーバー マシンとして存在します。MySQL データ フローは次のとおりです。

マスター --> マスター/スレーブ --> 問題のあるサーバー

3 台のマシンはすべて同一の仕様で、同じ会社でホストされています。問題のあるサーバーは、1 台目と 2 台目とは別のデータセンターにあります。

'iotop' ツールは、ディスク I/O が 'jbd2/sda7-8' プロセスによって発生していることを示しています。私たちが知っている限りでは、これはファイルシステムのジャーナリングとディスクへのフラッシュを処理します。'sda7' パーティションは '/var' で、sda8 パーティションは /home です。/home への定期的な読み取り/書き込みは行われません。mysql サービスを停止すると、ディスク I/O がすぐに通常のレベルに戻るため、問題の原因は percona であるとほぼ確信しています。これは、MySQL データ ディレクトリが存在する /var パーティション (/var/lib/mysql) と一致します。

当社では、NewRelic を使用してすべてのサーバーを監視していますが、ディスク I/O が急増しても、その原因となるものは何も見つかりません。負荷平均は ~2 です。CPU 使用率は ~25% で推移しており、NewRelic によると、これは特定のプロセスではなく「IO 待機」が原因です。

当社の MySQL 構成ファイルは、Percona 構成ウィザードと、お客様のアプリに必要ないくつかの設定を組み合わせて生成されましたが、特に特別なものではありません。

MySQL設定 -http://pastebin.com/5iev4eNa

問題を解決するために、次のことを試しました。

  • mysqltuner.pl を実行して、明らかに何か問題があるかどうかを確認しました。結果は、他の 2 つのデータベース サーバー上の同じツールの結果と非常に似ており、使用してもあまり変わりません。

  • vmstat、iotop、iostat、pt-diskstats、fatrace、lsof、pt-stalk などを使用しましたが、明らかな結果は出ませんでした。

  • 'innodb_flush_log_at_trx_commit' 変数を調整しました。0、1、2 に設定してみましたが、どれも効果がないようです。これにより、MySQL がトランザクションをログ ファイルにフラッシュする頻度が変更されるはずです。

  • ディスク I/O が高い場合、mysql の「show full processlist」はあまり面白くなく、マスターからのスレーブの読み取りを表示するだけです。

ツールからの出力の一部は明らかにかなり長いので、pastebin リンクを提供します。また、iotop の出力をコピーして貼り付けることができなかったので、代わりにスクリーン キャプチャを提供します。

iotop

IOトップ

pt-ディスク統計:http://pastebin.com/ZYdSkCsL

ディスク I/O が高い場合、「vmstat 2」は、書き込まれている内容のほとんどが「bo」（バッファ アウト）によるものであることを示しています。これは、ディスク ジャーナリング（バッファ/RAM をディスクにフラッシュする）と相関しています。

http://pastebin.com/E3LWzwjj

「lsof -p mysql-pid」（プロセスの開いているファイルを一覧表示）では、書き込まれているファイルは主に /var/lib/mysql ディレクトリの .MYI ファイルと .MYD ファイル、master.info ファイル、relay-bin ファイル、relay-log ファイルであることがわかります。mysql プロセス（つまり、サーバー全体に書き込まれているファイル）を指定しなくても、出力は非常に似ています（ほとんどが MySQL ファイルで、他にはほとんど何もない）これは、間違いなく Percona が原因であることを示しています。

ディスク I/O が高い場合、「seconds_behind_master」が増加します。現時点では、どちらの方向に発生するかはわかりません。また、「seconds_behind_master」は、通常値から一時的に任意の大きな値にジャンプし、その後すぐに通常値に戻ります。これはネットワークの問題が原因である可能性があると示唆する人もいます。

「スレーブステータスを表示」 -http://pastebin.com/Wj0tFina

RAID コントローラ (3ware 8006) にはキャッシュ機能がありません。また、キャッシュ パフォーマンスの低さが問題の原因である可能性もあると指摘する人もいました。コントローラのファームウェア、バージョン、リビジョンなどは、同じ顧客の他のサーバー (Web サーバーではありますが) のカードと同一であるため、コントローラに問題があるとは考えられません。アレイの検証も実行しましたが、結果は正常でした。また、変更があった場合に警告を発する RAID チェック スクリプトもあります。

ネットワーク速度は 2 番目のデータベース サーバーに比べてひどいので、これはネットワークの問題なのではないかと考えています。これは、ディスク I/O が高くなる直前の帯域幅の急上昇とも相関しています。ただし、ネットワークが「急上昇」しても、トラフィック量が急増することはなく、平均に比べて比較的高いだけです。

ネットワーク/ディスクIO

ネットワーク速度（AWS インスタンスへの iPerf を使用して生成）

問題のあるサーバー - 0.0-11.3 秒 2.25 MBytes 1.67 Mbits/秒 2 番目のサーバー - 0.0-10.0 秒 438 MBytes 366 Mbits/秒

遅いことを除けば、ネットワークは問題ないようです。パケットロスはありませんが、サーバー間のホップが遅いです。地下鉄

関連するコマンドの出力も喜んで提供しますが、私は新規ユーザーなので、この投稿にリンクを 2 つしか追加できません :(

編集この問題についてホスティング プロバイダーに連絡したところ、親切にもハード ディスクを同じサイズの SSD に交換してもらいました。これらの SSD に RAID を再構築しましたが、残念ながら問題は解決しません。

答え1

MySQLサーバのどのバージョンを使用していますか？5.5以降では、performance_schemaを使用してデータベースからリアルタイムの統計情報を取得できます。

 table_io_waits_summary_by_table
 table_io_waits_summary_by_table
 table_lock_waits_summary_by_table

何が起こっているのかを正確に確認します。

別の解決策としては、バッファ プールの使用状況を確認することです。メモリに移動する必要があるコールド ページが存在する可能性はありませんか?

答え2

それを攻撃する最良の方法は、http://www.brendangregg.com/linuxperf.htmlブレンダンのアドバイスに従ってください。

特に、ストレージに最もアクセスしているユーザーを知らせてくれる iosnoop ツールが必要です。しかし、このツールを最後まで読んで彼の思考プロセスと方法論を学ぶと、長期的には大きなメリットが得られるでしょう。

関連情報