Apacheが暴走してMySQLを強制終了するのはなぜですか？
Apacheは過去数日間で制御不能になり、MySQLを2回クラッシュさせました。私がWordPress WebサイトをphpBBフォーラムも含むウェブサイトに移行したとき、それはすべて始まりました。
サーバー管理の経験があまりないので、問題の原因を特定するのが非常に困難でした。 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
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マシンの方が適している可能性があります。小さいマシンは大きいマシンの価格のちょうど半分なので、コストは同じです...すでに前払いしたとしても追加割引については、 この変更は実現可能 です。
チェックするいくつかのポイントがあります：
-/ var/log/messagesを確認します。使用するメモリがなくなった場合、oomkillerはmysqlプロセスを強制終了できます。 free -lm（キャッシュなし）でRAMをチェックします
-prefork mpmでApacheを使用している場合：プロセス数を確認します。 Apacheがmysqlへのリンクを使用して重要な数のプロセス（大量のワークロード中に）をスタックする場合、レイテンシと使用されるメモリが急速に増大する可能性があります。
mysqlによって起動されたスレッドの数をshow global statusで確認します。threads_cached、threads_created、threads_runningは確認することが重要です（threads_createdは0に近いはずです）。
-Mysqlが使用するRAMを確認します。
cpusets の実装とmysqlのリソースの予約を検討することもできます。これは、これらのサービスをさまざまなハードウェアで実行するのに最も近いものですが、単一のサーバーを維持するという利点があります。