☰

Percona XtraDB Cluster での繰り返しのロックと速度低下

tag-icon • tag-icon percona percona-xtradb-cluster xtradb
Percona XtraDB Cluster での繰り返しのロックと速度低下

私は Percona XtraDB Cluster で構成された 5 台の専用サーバー (同一マシン: 32 コア、96 GB の RAM、RAID 内の SSD ドライブ、ギガビット イーサネット リンク) を所有しています。

繰り返し発生する問題により、クラスターの速度が通常 30 ～ 60 秒ほど大幅に低下しますが、5 ～ 10 分間停止することもあります。

このシステムは、Web サイトの混雑したネットワークに使用され、各 Web サーバーで mysql-proxy を使用して、データベースへのトラフィックの負荷を分散します。

1 つのノードのみが有効になっている場合、この問題は発生しません。代わりに、ノードが追加されるたびに、問題の深刻度 (クエリが遅くなる/ロックされる時間) が増し、4 つのノードがアクティブになると非常に耐え難い状態になります (この時点でクラスターは自動的に回復できなくなります)。

詳細な症状は次のとおりです。

  1. 5 ～ 15 分ごとに、すべての書き込みクエリ (INSERT/UPDATE) が各ノードのキューで停止します。クエリの中には 45 ～ 50 秒後にディスパッチされるものもありますが、完全に停止しているものもあります。
  2. ほとんどの場合、30 ～ 60 秒後にはクラスターが何らかの形で追いつき、1 ～ 2 秒以内にクエリを迅速にディスパッチします。
  3. 場合によっては、クラスターがこれらのスタックしたクエリを自動的に処理できないため、最も混雑している Web サイトを手動で無効にして負荷を軽減する必要があります。負荷がほとんどない状態が 30 秒ほど続いた後、クラスターは再びすべてのクエリをディスパッチできるようになります。

  4. エラー ログは通常はクリーンで、速度低下が発生する前も後もエラー メッセージは表示されません。まれに次のようなログが表示されることがあります (10 回に 1 回程度)。

    130906 9:53:27 [注記] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') メッセージリレー要求をオンにしています、非ライブピア: tcp://IPOFONEOFTHENODES

    130906 9:53:27 [注記] WSREP: (3f3abd42-15bc-11e3-b38b-2e049b972e3b, 'tcp://0.0.0.0:4567') メッセージリレー要求をオフにします

  5. 通常、通常の負荷では wsrep_cert_deps_distance は約 400 です。速度低下が始まるとすぐに、wsrep_cert_deps_distance は 2k-3k の範囲までゆっくりと増加します (3k マークに達すると、アプリケーションを手動で無効にする必要があります。そうしないと、クラスターは自動的に回復できません)。

  6. mytop と atop で監視すると、サーバーまたは mysql プロセスに高い負荷がかかっていないことがわかります。CPU 使用率は、通常の操作時とスローダウン時の両方で常に適度に低くなっています (最大値の約 25%)。I/O 使用率は良好で、十分な RAM 空き容量があり、vmcom は制限以下です。

myq_status を使用して、各ノードのクラスターをリアルタイムで監視すると、次のような結果になります。

  • 速度低下が発生した場合でも、wsrep_flow_control_paused 変数は常に 0.0 になります。
  • wsrep_local_bf_aborts または wsrep_local_cert_failures は発生しません。
  • 各ノードのアウトバウンド レプリケーションは通常 0 ですが、速度低下が発生すると 200 ～ 300 まで増加します。
  • インバウンド レプリケーションは、すべてのノードで常に 0 です (まれに 1 になることがありますが、通常の負荷でも発生します)。明らかにクラスター内に遅いノードがないので、これは不思議です。
  • 速度低下が始まってから 10 ～ 15 秒後、送受信されるオペレーションとバイトはすべてのノードで 0 になります。1 ～ 2 秒間 0 のままですが、次の 1 秒間にオペレーションとバイト数が増加し、多数の「oooe」オペレーション (アウトオブオーダー実行) が発生します。サーバーが正常に戻るまで、この状態が数秒ごとに繰り返されます。

問題のトラブルシューティングを試みるために実行したテストの詳細は次のとおりです (うまくいきませんでしたが...)。

  1. まずネットワークをチェックしました。サーバーは専用のギガビット ネットワークと同じラックにあり、パケット損失やその他の明らかなネットワークの問題もなく、すべて正常に動作しているようです。
  2. 帯域幅の使用状況を確認したところ、各ノードは平均 30 ～ 100 mbps (メガビット) の帯域幅を使用しています。「iftop」を使用してリアルタイムで確認したところ、問題が発生している間の帯域幅の使用状況は通常、平均 (15 ～ 30 mbps) 未満です。ノードの同期中は帯域幅が 800 ～ 900 mbps (本来あるべき値) まで上昇するため、ネットワークが飽和状態になっているとは考えられません。
  3. 特定のノードが他のすべてに影響を与えているかどうかを確認するために、すべてのノードの組み合わせを試しました。どのノードを無効にしたり使用したりしても、常に問題が発生します。この問題は常に、同時にアクティブなノードの数に関連しています。

同様の問題に遭遇した人はいますか? よろしくお願いします!

関連情報