web-dev-qa-db-ja.com

ハングしているLinuxサーバーのトラブルシューティング方法

離れた場所にいくつかのUbuntuServer8.04マシンがあります。数か月ごとに、そのうちの1つが応答を停止し、電源を入れ直す必要があります。ログファイルを見ると、ある時点ですべてが停止するまで、すべてのプロセスが正常に実行されているようです。

ハードウェアの問題だと思いますが、問題の特定を開始する方法すらわかりません。この種の問題を追跡するために設計された診断ツールまたは技術はありますか?

私はこれがかなり一般的な質問であることを知っていますが、私は一般的な答えを望んでいます。

3
itsadok

別のマシンを接続し、シリアルコンソールを構成して、発生するすべてのカーネルメッセージなどを取得します。カーネルパニックやその他の壊滅的な問題の場合は、そこに表示されます。特にホイールが落ちる前にコンソールに異常が見られない場合は、温度を監視してmemtestを実行することもお勧めします。

3
womble

Memtest が最初の呼び出しポイントになりますが、可能であれば、次にクラッシュしたときにコンソールを接続するようにセンターに依頼してください。カーネルが機能している場合は、画面に何かを出力する必要があります。

3
Ryaner

私は過去に同様の問題を抱えていました、そしてそれは熱に関連していることがわかりました。循環を改善し、ファンを1つか2つ追加することは、大きな助けになりました。

また、ディスクでSMARTが有効になっていることを確認し、そのうちの1つが最後のレッグにあるかどうかを確認してください。

Muninをインストールして、それらすべてを監視し、何が起こっているかを確認することをお勧めします。

3
Paul Tomblin

Zabbixのような包括的なリモートモニタリングソリューションを導入します。システムリソースの使用状況の側面、およびオペレーティングシステムで利用可能なハードウェア統計(ファンの速度、温度など)を監視します。そうすれば、次にシステムがフォールオーバーしたときに、問題が何であるかを確認するために確認できるデータポイントがいくつかあります。

このアプローチでは、たとえば、RAM割り当てで制御不能になり、システムをスワップにプッシュし、メモリ不足キラーがその切り分けを開始するプロセスがあることに気付く場合があります。実行中のプロセスを通過し、マシンを応答しないままにします。監視がなければ、それを知ることはできませんでした。

1
Jon Topper

明らかに機能するものに実際に与えられる情報が少なすぎます。

応答の「停止」をどのように定義するかを知っておくとよいでしょうか。応答を停止するのはsshだけですか、それとも他のサービスですか?コンソールがまだ応答している場合、何かアイデアはありますか?

再起動後にマシンがオンラインに戻った後のログファイルのトレースはありますか?

とにかく情報収集を進めるためのいくつかのオプション:

  • シリアル回線でgettyを有効にし、シリアルサーバーの購入に苦労しない場合は、マシン間でシリアルを相互配線します。ネットワーク経由で1台のマシンにアクセスできない場合は、シリアル経由でアクセスを試みることができます。
  • 監視ソフトウェアをインストールし、lmsensors、スマートツールテックからステータスを取得します。
  • syslogをリモートマシンに送信します。
1
rasjani