web-dev-qa-db-ja.com

99％ディスクIO Perconaでスパイク

そのため、ディスクI/Oにランダムなスパイクが見られ、ランダムな時間に99.x％まで上昇し、明白な理由もなく、しばらくの間ハイのままで、その後ダウンするサーバーがあります。これは以前は問題ではありませんでしたが、最近、ディスクI/Oは長期間（場合によっては最大16時間）99％のままになっています。

サーバーは、4つのCPUコアと4GBのRAMを備えた専用サーバーです。 Ubuntu Server 14.04.2を実行し、percona-server 5.6を実行しており、他に主要なものはありません。ダウンタイムが監視されており、処理するサーバーのCPU/RAM /ディスクI/Oを永続的に表示する画面があります。サーバーにも定期的にパッチが適用され、保守されています。

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

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

3台のマシンはすべて同じ仕様で、同じ会社でホストされています。問題のあるサーバーは、最初と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がトランザクションをログファイルにフラッシュする頻度が変更されたはずです。

  • Mysqlの「showfullprocesslist」は、disk-I/Oが高い場合は非常に興味深いものではなく、マスターからのスレーブの読み取り値を表示するだけです。

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

iotop

IOTop

pt-diskstats： http://Pastebin.com/ZYdSkCsL

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

http://Pastebin.com/E3LWzwjj

「lsof-pmysql-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がハイになる直前の帯域幅のスパイクとも相関しています。ただし、ネットワークが「スパイク」した場合でも、大量のトラフィックにスパイクすることはなく、平均と比較して比較的多いだけです。

Network/Disk IO

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

問題のあるサーバー-0.0-11.3秒2.25メガバイト1.67メガビット/秒2番目のサーバー-0.0-10.0秒438メガバイト366メガビット/秒

遅いことは別として、ネットワークは問題ないようです。パケット損失はありませんが、サーバー間のホップが遅くなります MTR

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

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

linuxmysqlhard-driveiopercona
4
user284587

それを攻撃する最良の方法は、 http://www.brendangregg.com/linuxperf.html を見て、ブレンダンのアドバイスに従うことです。

具体的には、誰がストレージに最もアクセスするかを教えてくれる彼のiosnoopツールが必要です。しかし、それを読んで彼の思考プロセスと方法論を学ぶと、長期的には多くの利益が得られるので、あなたは自分自身に大きな恩恵をもたらすでしょう。

1
Baruch Even

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

 table_io_waits_summary_by_table
 table_io_waits_summary_by_table
 table_lock_waits_summary_by_table

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

別の解決策は、バッファプールの使用状況を確認した場合、メモリに移動する必要のあるコールドページがあることは不可能ですか？

1
banyek