web-dev-qa-db-ja.com

DebianLinuxサーバーが1週間ほどでハングする

奇妙な動作をするDebianLinux6.0.4サーバーが2台あります。5-7-10日後にハングします。これは、サーバーを再起動する必要があり、その前にpingが応答しないことを意味します。

私はこの問題に数ヶ月苦労してきましたが、ここにいくつかの考え/問題を解決できずに試したことがあります。

  • サーバーのRAMを変更しました。2つの異なるサーバーであるため、3番目の同一サーバーではこの問題が発生しないため、ハードウェアに関連するものである可能性はありません。
  • サーバーの負荷をログに記録しましたが、クラッシュしても負荷は問題ありません（かなり低い）
  • サーバーログに何も見つかりません。サーバーがフリーズするまでログは問題ありません。
  • 残念ながら、コンソールにアクセスできません。

私は長年の管理経験がありますが、そのような問題に遭遇したことはなく、今のところ他にどこを調査すればよいかわかりません。

問題を解決するために私が何を試すことができるかについての考えがあれば、それを私と共有してください:-)

debianhangs
1
Alex Flo

どうやら問題はサーバーをハングさせる原因となったいくつかのpythonスクリプトに関連していたようです。なぜサーバーをハングさせたのかわかりませんが、少なくとももうハングしません。

0
Alex Flo

/ var/log/messagesおよび/または/var/log/kern.logの関連コンテンツを表示してください。カーネルがクラッシュレポートやその他の光を当てる可能性のあるものをログに記録した可能性があります。このような原因不明のハングを経験したとき、それは悪いドライバーが原因でした。ロギングがあまり冗長ではないため、正確なドライバーを見つけることができませんでした。

私の場合、ソフトロックアップがありました（カーネル：[XXXX]バグ：ソフトロックアップ-CPU＃X）。いくつかの調査の後、私は http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=5560 を見つけました。最後のコメントは、ロギングをより冗長にするための洞察と方法を提供しました。これは簡単なカーネルの変更ですが、独自のカーネルをコンパイルすることに抵抗がある場合は、それが最善の方法ではない可能性があります。

カーネルを更新するか、新しいバージョンをインストールして再起動するだけで問題が解決する場合があります。

引用：

私たちはこの問題を広範囲に調査しました。

TLBフラッシュソフトロックアップは、デッドロックの結果にすぎません。

背景：TLBフラッシュは、CPUによって、プロセッサ間割り込みを使用して他の多くのCPUに発行され、ページングの変更を伝播します。次に、発行元のCPUは、すべてのプロセッサが変更を確認するまでループします。そのようなプロセッサがスピンロックでデッドロック状態にある場合、これは決して起こりません。その後、ソフトロックアップがトリガーされます。デッドロックはスピンロックで発生します。このロックは、ユーザーコードによって保持される場合があります（モジュールの/ procまたは/ sysインターフェイスを介して）。

根本原因（つまり、どのドライバーが問題を引き起こしているのか）を特定する唯一の方法は、すべてのCPUスタックをソフトロックアップコードにダンプすることです。

これを行う1つの方法は、カーネルを変更して追加することです。

            Arch_trigger_all_cpu_backtrace()

の中に

            kernel/softlockup.c:softlockup_tick()

関数。

これはNMI IPIに基づいており、デッドロックの場合でもすべてのスタックがダンプされることを保証します（不可能が発生することも期待しないでください）。

障害のあるドライバーを簡単に見つけて、関連するバグを投稿する必要があります。

1
aseq

サーバーは本当にハングしますか、それともpingで到達できませんか？

CPU負荷だけでなく、メモリ統計、ディスク使用量、その他のさまざまな要素のグラフを表示するMunin（または同様のもの）などの監視ツールをインストールします。さまざまな側面を監視するように構成できます。サーバーがハングした場合は、グラフで異常な兆候がないか確認してください。通常のグラフがどのように見えるかを学習するので、通常とは異なるものは疑わしいものになります（必ずしも間違っているとは限りません）。

すべてのサーバーログを確認していますか？つまり、web/mail/ftp/dns/otherサーバーはありますか？そのようなログをすべてチェックしてください！トラブルシューティング中にデバッグログを有効にすることを忘れないでください。

サーバーが毎週クラッシュする場合は、定期的に発生する可能性があります。たとえば、cronジョブやログローテーションなどです。

すべてのシステムメール（ルートエイリアス）を取得していることを確認してください。 OSSECをインストールすることもできます。これは、ログを監視し、問題が発生したときに電子メールを受信するための優れたツールです。ただし、このOSSECツールはログを自動化して表示する方法であるため、魔法のようなものはありません。

ネットワークの問題？ dhcpリースの有効期限が切れていますか？

1
snostorm