Ubuntu Natty/11.04 で LAMP を実行している Amazon EC2 インスタンスがあります。過去数か月間に 3 回、そのうち 2 回は過去 2 週間で、サーバーが突然停止しました。応答しなくなり、接続試行 (SSH など) に応答しなくなりましたが、EC2 コントロール パネルでは引き続き実行中として報告されています。そのたびに、コンソールからインスタンスを再起動する必要があり、その結果データが失われました。
そこで、今、問題を診断しようとしていますが、何もわからず、他に何をチェックすればよいかアドバイスが必要です。Syslog には疑わしいものは何もありません。各ケースで最後に起こったことは、munin が通常の 5 分間の cronjob を実行していたことですが、マシンがいつ動作を停止したか正確にはわからないため、cron ログがフリーズにどれだけ近いかはわかりません。その後は、マシンが再起動されるまでは単に動作していなかったかのようで、その後、syslog には通常の dmesg 出力のように見えるものが含まれます。
交通量とフリーズの発生時間には相関関係がないようです。それぞれのフリーズの発生時間は、交通量のピーク時間からかなり離れています。
これらの問題の原因を突き止めるために、他に何を確認すればよいでしょうか? 問題は何でしょうか?
追記: サーバーがダウンしたとき、サーバーに高い負荷がかかっていたわけではありません。CPU とメモリの使用量はどちらも制限内であり、安全でした。ディスクの空き容量は十分にありました (数十ギガバイト)。Apache や MySQL のログにも異常はなく、その時点で動作が停止しただけです。これは中/高 CPU インスタンスです。
答え1
最初にすべきことは、サーバーが応答しなくなったときに通知する監視を設定することです。pingdom や cloudwatch を使用して、サービスの稼働時間と CPU や RAM などのシステム統計をチェックすることでこれを行うことができます。どちらも小規模アカウント向けの無料プランがあります。これにより、いつダウンしたかを把握でき、その瞬間に何が起こっていたかについてログを簡単に調べることができます。通常、このような問題は、システムに十分なリソースがないために発生する可能性があります。インスタンスのサイズについては言及されていませんが、マイクロのようなものが単純な cron ジョブによって 100% の CPU を固定し、その時点でサーバーがロックアップする可能性があります。
また、syslog 以外のログも確認し、システムがダウンする前にすべてのアプリ ログをチェックして、エラーが発生していないかどうかを確認します。
答え2
ホストマシンの NIC が不良である可能性があります。