なぜApacheは暴走してMySQLを殺してしまうのですか?


8

Apacheは過去数日間で制御不能になり、MySQLを2回クラッシュさせました。phpBBフォーラムも含まれているWordPress Webサイトを移行したときにすべてが始まりました。

サーバー管理の経験があまりないので、問題の原因を特定するのが非常に困難でした。MySQLがダウンしていることに気づいたとき、私はTOPを実行し、システム負荷が98.00に急上昇するのを見ました。サーバーは10個のV-HOSTSを実行しており、そのすべてが正常な量のトラフィックを受信して​​いるため、明らかに多くのapache-2プロセスが実行されているのがわかりました。

サーバーの高負荷が10分間続いた後、通常の状態に戻りました。この時点では、ネットワークトラフィックの急増は見られませんでした。

残念ながら、MySQLエラーロギングは無効になっている(現在は再度有効になっている)ため、手掛かりはありません。しかし、それはApacheがすべてのリソースを消費していたため、MySQLプロセスIDが強制終了されたためだと確信しています。

私の質問は:

次回これが発生した場合-システム負荷の急上昇の原因を特定するにはどうすればよいですか?クレイジーになったphpスクリプトでしょうか?DDOS攻撃か?

MySQLがクラッシュしたときに自動的にMySQLを再起動する方法はありますか?

インストールしましたhtop。これはもっと便利topでしょうか?

ここに私のサーバー統計:

m1.xlarge (8 ECUs, 4 vCPUs, 15 GiB memory, 4 x 420 GiB Storage Capacity)
Ubuntu Server 12.04.3 LTS 

ログは無効になっていますが、役に立ちdmesgますか?
ダニエルW.

回答:


9

MySQLはまだ何もログに記録しない可能性があります。これは、Apacheの子によるシステムメモリのプレッシャーが原因で、システムによって不正に強制終了されているためです。/ var / log / syslogにこの痕跡があるはずです。

MySQLは、クラッシュまたは強制終了で再起動を試行する必要がありますが、十分なメモリが利用可能でない場合、それを行うことはできません...そして、この2番目のエラーは、mysqld_safeでは「クラッシュ」としてではなく、「拒否開始する」ので、それは試み続けることはありません。失敗した再起動の試みは、多くの場合、管理者によって「クラッシュ」として誤って解釈されます。これは、元の失敗の性質がMySQLエラーログの見落とされがちなメッセージの背後に隠されているためです。

mysqld_safe Number of processes running now: 0

InnoDB Crash Post Mortemを参照して、私と同じ状況だと思います。

「なぜ」に対する一見単純な答えは、ApacheとMySQL、現在の負荷、および現在の構成の間で、マシンに十分なメモリがないことであり、この状態を引き起こすトラフィック負荷に関連するいくつかの転換点があります。

Apacheは子プロセスからの同時ブラウザー要求を処理するため、同時接続数が増えると、子の数が増えます。最初に、Apache構成でこの値を制限して、実際に同時接続の増加を引き起こしている原因を理解できるようにする必要があります...それは単に重いが正当なトラフィックスパイクですか?ある種のサービス拒否?実行時間が長すぎるためにリクエストを遅延させるDBクエリ?最適化が必要ですか?

http://httpd.apache.org/docs/2.2/mod/mpm_common.html#maxclients

並行Apacheプロセスを制限することでこれを防ぐことができますが、明確にするために、これが完全なソリューションであると考えるのは初心者なので、それを暗示するつもりはありません。プロセスが合理的または少なくともより安全なレベルに制限されると、実際に何が起こっているかを特定することができます。(Apacheには他にも拘束制御がありますが、それは私の専門分野ではありません。)

「ベストプラクティス」はもちろん、アプリケーションがデータベースを強制終了できないように、データベースをさまざまなハードウェアで実行することです。表面的には、1台のマシンを共有することで「使用率を最大化」する方が効率的ですが、これは誤った経済です。MySQLが使用するメモリの大部分は、標準的なワークロードで、起動時に割り当てられ、MySQLサーバーが実行されている限り保持されます。CPUへの要求は、MySQLとApacheのピーク時間を共有する可能性があります。これは、それらが最終的に同じ負荷を処理するためです。実際には、1台のm1.xlargeではなく2台のm1.largeマシンを使用する方が良いかもしれません。小さいマシンは大きいマシンの価格のちょうど半分なので、コストは同じです...すでに前払いしたとしても追加の割引については、この変更を行うことができます


お返事ありがとうございます。/ ver / log / syslogを確認したところ、次の行が見つかりました:Dec 18 15:48:38 ip-10-33-164-173 kernel:[29714591.071719] Out of memory:Kill process 28369(mysqld)score 21 or sacrifice child Dec 18 15:48:38 ip-10-33-164-173 kernel:[29714591.071753] killed process 28369(mysqld)total-vm:2520332kB、anon-rss:335304kB、file-rss:0kBしたがって、これを防ぐには、Apacheのmaxclients設定が最善の策でしょうか。安全な値は何だと思いますか?
ボブフレミング

1
maxclientsを制限することが、発生している雪崩の原因となる状況を理解するプロセスを開始するための最良の方法であることをお勧めします。状況、システムの空きメモリの量、Apacheの子供たちが使用しているメモリの一般的な量に基づいて、より安全な値を算出する必要があります。少なすぎると、リクエストのバックアップが開始されます。高すぎるし、あなたは今あなたがいるところです。次に、生成されたプロセスを監視し、空きメモリとサーバーログを確認します。
マイケル-sqlbot '19

1

チェックするいくつかのポイントがあります:

/ var / log / messagesを確認します。使用するメモリがなくなった場合、oomkillerはmysqlプロセスを強制終了できます。free -lm(キャッシュなし)でRAMをチェックします

-prefork mpmでapacheを使用する場合:プロセス数を確認します。Apacheがmysqlへのリンクを使用して重要な数のプロセス(大量のワークロード中に)をスタックする場合、レイテンシと使用されるメモリが急速に増大する可能性があります。

-mysql によって起動されたスレッドの数をshow globalステータスで確認します。threads_cached、threads_created、threads_runningは確認することが重要です(threads_createdは0に近いはずです)。

-Mysqlが使用するRAMを確認します。


0

また、mysqlのcpusetsの実装とリソースの予約を検討することもできます。これは、これらのサービスをさまざまなハードウェアで実行するのに最も近いものですが、単一のサーバーを維持するという利点があります。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.