Linuxマシンのデバッグがフリーズする

15の同一のLinux RH 4.7 64ビットサーバーがあります。クラスタデータベースを実行します（クラスタはアプリケーションレベルです）。時々（毎月かそこら）ランダムなボックス（決して同じではありません）がフリーズします。

私は箱にpingを送信でき、pingが機能します。ボックスでsshしようとすると、次のようになります。

ssh_exchange_identification: Connection closed by remote host

SSHが正しく設定されている。

サーバールームに行ってコンソールに直接ログインしようとすると、Alt+ Fnでコンソールを切り替えたり、ユーザー名を入力したり、文字を表示したりできますが、を押した後Enter、何も起こりません。一度8時間待っても変わらなかった。

すべてをリモートホストに記録するようにsyslogを設定しましたが、それらのログには何も記録されていません。マシンを再起動すると、問題なく動作します。私はHWテストを実行しました-すべて問題なく、ログには何もありません。マシンはNAGIOSでも監視されており、フリーズする前に異常な負荷やアクティビティが発生することはありません。

アイデアが足りません。他に何ができるか、または確認できますか？

カーネルがパニックして、sshdがサーバーキーを送信できなかったようです。おそらく、カーネルはネットワークスタックがまだ稼働しているような方法で押し込まれていましたが、vfsレイヤーが利用できませんでした。

RHEL4システムで同様の問題が発生したとき、netdumpとnetconsoleサービスをセットアップし、専用のnetdumpとsyslogサーバーを設定して、クラッシュダンプとカーネルパニック情報をキャッチしました。また、kernel.panic sysctlを10に設定しました。このようにして、システムパニックが発生すると、カーネルトレースとそのシステム上のメモリのコピーの両方が取得され、「crash」ユーティリティで分析できます。

また、ホスト用のシリアルコンソールをセットアップすることでメリットが得られるので、コンソールが出力され、マジックsysrqキーがヒットする可能性があります。また、ネットワークを設定する予定があり、それをサポートするハードウェアがある場合は、IPMIを使用して、リモートで電源をオフにしたり、電源を入れたり、再起動したり、ハードウェアにクエリを実行したりできます。

（それだけの価値があるため、RHEL5にはkexec / kdumpと同様の機能があり、クラッシュダンプのみがローカルに保存されます）

私はあなたがメモリ不足になっているドーナツにドルを賭けます。システムは、どこから取得するかを理解しようとするため、停止します。非常に迅速に発生しているため、監視がそれを把握できない場合があります。メモリ使用量のリモートロギングを含め、監視を強化します。OOMメッセージのログも確認してください。

（いくつかのsshウィンドウを開いて実行したい場合さえあるかもしれません。）

私にはこれはシステムのリソースが不足しているように聞こえるので、sshのサーバー側で必要なプロセスを割り当てることができません。

実際のボトルネックはさまざまです-プロセス外またはメモリ不足-確認する唯一の方法は、ログとコンソールを調べて、そこに何かが存在するかどうかを確認することです。事前に開始されたsshジョブのシナリオ（各マシンに1つ）をセットアップして、次に発生したときに備えておくとよいでしょう。

それが本当に悪い場合は、より多くの組み込みコマンドを使用して別のシェルを開始することを検討してください。これにより、追加のプロセスを開始する必要がないため、さらに調査することができます。また、「tail -f / var / log / *」も非常に便利です。

幸運を。

KVMスイッチが使用されており、キーボードホットキー（例：alt + n）がサーバー間の切り替えに使用されていたのは、私がこれに似たものを見たときだけです。これは毎回発生するわけではなく、影響を受けたサーバーから切り替わっていたため、すぐには気付きませんでした。KVMスイッチ自体の物理ボタンがサーバー間の切り替えに使用された場合、ロックアップは発生しません。ホットキーが頻繁に使用された場合、サーバーが新しいログインを許可しないことがあります。既存のSSHセッションは影響を受けません。