web-dev-qa-db-ja.com

Debian Stretch VMは数日ごとに準応答しなくなります

影響を受けるコンピューターはVM vSphereで実行されており、本番サーバーであるため、問題が醜い頭を抱えると、トラブルシューティングの時間は通常存在しません。問題は再起動後に解消され、システムはその後約1週間は安定しているようですが、どうすればよいか、また発生したときに何を探すかについてのアイデアを探しています（現在のパターンが当てはまる場合は、おそらく今週の木曜日または金曜日頃）。

VMはpingに正常に応答し、http/sリクエストをリッスンしますが、応答しません（Apache2 ）SSHもリッスンしますが、セッションを閉じる前に認証を求めるプロンプトを表示することはありません。

「ローカル」コンソールは、コマンドを送信した直後にハングします。その時点までは、好きなように入力できます。システムにdoを実行するように要求した後でのみ、システムは機能しなくなります。これには、ファイル名にタブ補完を使用する試みなどが含まれます。他の仮想端末の1つに切り替えて、ユーザー名とパスワードを入力できますが、システムが再びハングします。

クラッシュに関する情報は、/ var/logのログにはありません（他の場所にあるポインタを調べてください）。ログファイルの最後のメッセージは、実際の問題が発生するずっと前に書き込まれます。

追加情報：

この問題が発生した場合、VMの「ローカルコンソール」には何も出力されません。このVMには、LSI Logic Parallel vSCSIを介して接続された単一の1TBボリューム（シックプロビジョニング、レイジーゼロ）があります。データストア自体は大規模ですNAS他のESXiホストはほとんどなく、これが発生しても他のゲストは影響を受けません。

この問題が発生しても、vCenter/vSphereは異常に高いCPUまたはメモリ使用率を示しません。

少なくとも1回は、SFTP経由でサーバーにアクセスしようとしている誰かに気付かれる前に、ハングが8時間以上続いています。

Sourcejediの推奨に従って、コンソールロギングのしきい値を5に下げ、VMのローカルコンソールで/ dev/kmsgに送信されたメッセージを確認できることを確認しました。これらのメッセージは、変更を加える前は表示されなかったため、カーネルが何かを言おうとしていた可能性がありますが、私はそれを見たことがありません。

ESXiホストに余裕のあるリソースがあるため、VMのクローンを作成し、別の分離されたネットワークに配置しました。この問題が発生した場合は、さらに時間がかかります。プロセス中に本番サービスがダウンすることを心配することなく、トラブルシューティングを行います。

詳細がわかり次第更新しますが、これまでにご協力いただいた皆様、ありがとうございました！

debiancrashhang
3
deletesystem32
  1. 仮定
  2. 指示
  3. ばかげたハック（タスクがファイルシステム/ディスクアクセスでハングしていることを前提としています）

1.前提条件

1.1）デフォルトでは、Linuxカーネルにはさまざまなタイプのクラッシュまたはハングを報告するコードがあります。

それらはすべて、当面の問題を示し、「ローカルコンソール」にコールチェーンを出力できます。根本的な原因が示されていない可能性があり、このコードが100％信頼できるとは限りません。しかし、通常、あなたは何かを手に入れます、そしてそれは何もないよりずっと良いです。

したがって、これらのカーネルログメッセージがコンソールに表示されることを再確認する必要があります。詳細は次のセクションにあります。

1.2）カーネル自体はまだキーの押下とネットワークパケットに応答しているので、ハングしたタスク検出器がここで機能することを本当に期待しています。

カーネルスレッドと割り込みはまだ機能しているようですが、ユーザースペースプロセスがハングしています。この症状は、プロセスが物理ファイルシステムにアクセスしようとしたときのハングと一致しているように聞こえます。プロセスが数分間ハングすると、カーネルは「ハングしたタスク」メッセージと呼び出しチェーンを出力します。

1.3）あるいは、ユーザープロセスが完全にハングしているわけではありませんが、非常に遅く、進行状況を確認するのに「十分な時間」待機していません。 。

メカニカルHDDを搭載したLinuxPCの使用経験がある場合は、この話に精通しているかもしれません:-)。ただし、これはデスク上のPCではないため、ハードディスクのノイズが非常に多いことや、ディスクアクティビティライトが常時点灯していることに気付くことはありません:-)。

私はサーバーの管理の経験がありません。しかし、このような問題を検出するには、監視ソフトウェアを使用する必要があると思います。理想的には、ユーザーに見える問題が発生する前でも:-)。

一例を挙げると、システムのメモリ使用量を監視すると、徐々に「メモリリーク」が発生し、システムがスワップを開始して停止するかどうかがわかります。私はあなたがその問題を抱えていないことを期待しています。例えば。 loginがスワップアウトされていた場合、コンソールログインは遅くなり、パスワードの入力を求めることさえできませんでした。

十分にきめ細かい監視が行われていれば、障害が観察される数秒前にディスクIOの上昇を検出する可能性があります。

2.手順

2.1）「ローカルコンソール」はログに記録されているか、少なくとも永続的であるため、カーネルクラッシュが出力された場合に気付くでしょう。本当にそうあるべきですが、エミュレートされたserialコンソールを使用した場合にvSphereなどがどのように機能するかはよくわかりません。エミュレートされたビデオディスプレイを使用しているだけの場合は、すでに永続化されています。

このVMWareの記事 同じ仮定に依存しているようです。

2.2）コンソールロギングを無効にしていないことを確認してください。 次のコマンドを実行します。

Sudo sh -c "echo '<3>test' >/dev/kmsg"

コンソールに「test」と表示されます。スタックトレースについて説明している以下も参照してください。

これがエミュレートされたビデオディスプレイの場合、クラッシュメッセージの一部が画面の上部からスクロールして外れることがあります。また、カーネルにcrashedがある場合、shift + PageUpを使用して上にスクロールすることはできません。原則として、スクロールバックを実装するエミュレートされたシリアルコンソールがあると便利です。

カーネルクラッシュの場合、上記のVMWareリンクに他のクラッシュダンプの提案がいくつかあります。

2.3）パスワードを入力した後のハングは、ディスクが応答しなくなったように聞こえます。 Linux SCSIはしばらくすると操作をタイムアウトし、タイムアウトはカーネルエラーとしてログに記録されるので、Linuxはそれらをコンソールに出力すると思います。 ファイルシステムはSCSIプロトコルなどを使用してマウントされていますか？

2.4）また、デフォルトでは、カーネルはハングしたタスクを検出し、メッセージtask bash:999 blocked for more than 120 secondsを出力します。その後にコールチェーン（「スタックトレース」）が続きます。ただし、コールチェーン部分はカーネルの「デフォルトのログレベル」を使用してログに記録されると思います。これはほとんどの場合、レベル4（警告）を意味します。

ハングしたタスクメッセージのコールチェーン部分を表示する場合は、コンソールログレベルをレベル4より上に上げる必要があります。 dmesg -n 5。

ハングしたタスクメッセージを無効にしていないことを確認するには：cat /proc/sys/kernel/hung_task_timeout_secsに正の数を表示する必要があります。 120。

ハングしたタスクメッセージは出力されません ネットワークファイルシステムがハングした場合 。それらは、ハングしたタスクが「中断不可能」と「殺せない」の両方である場合にのみ印刷されます。 NFSでハングしたプロセスは強制終了できます 。このハングを引き起こす可能性のあるネットワークファイルシステムを使用している場合は、すでにこれについて考えている可能性があります。 （NFSサーバーへの接続を何らかの方法でテストするだけでなく、justハングしたVM with ping、そしてあなたは質問でこれすべてに言及したでしょう:-) NFSサーバーが他のVMから応答しているように見えても、このVMでハングしたタスクメッセージが表示されない場合は、を使用して調査を試みることができると思いますsysrq + T（以下を参照）。

ハングタスクメッセージは、DebianLinuxビルドでデフォルトで有効になっています。 （何らかの理由で、私のFedora Linuxカーネルは、ハングしたタスク検出器をまったく含まずに構築されています。RHELおよびSLESカーネルに含まれているように見えますが。FIXME）。

ハングしたタスクメッセージを検索したところ、ハングしたサーバーとIOエラーメッセージが共通のテーマのようでした:-)の両方に気づきました。

Linux sysrqもあります。シリアルコンソールを使用していて、接続した後にのみ印刷された出力をキャプチャできる場合は、たとえば、 sysrq + Tを使用してハングしたタスクを探してみてください。これにより、システム上のeveryタスクに関する情報がダンプされるため、lotが生成されます。 ）コンソールへの出力。したがって、コンソールがビデオディスプレイの場合、これはあまり役に立たない可能性があります。また、稼働中の本番システムでこれをテストしないでください。一部のディストリビューションでは、物理的なセキュリティ上の理由から、デフォルトでsysrqが無効になっています。 Debianはsysrqを有効のままにします。もちろん、sysrqを無効にするように指示されたセキュリティチェックリストを使用した可能性があります。

2.4）元の質問では、観察された障害の直前、またはシステムが頻繁に過負荷になっていないことを示すために、「応答性」の定量的監視を引用していませんでした（これは最終的な拡張である可能性があります）。

さまざまなサービスについて、サービスの「応答性」を定量的に監視することの価値を検討してください。これには、sshサーバーへのログインが含まれる場合があります。また、システム使用率レベル、遅延、および1秒あたりのネットワークパケット。

P.S. diskbusy％ と "CPU iowait" の両方が呪われている可能性があります。現在のディスクレイテンシとIOPSも監視したいと思います。 （現在のDebian 9.xカーネルは、ディスクビジー％については比較的賢明なはずです）。

上記の回答とVMwareリンクでは、学習する必要がある、または少なくともそれらの存在を認識している必要がある標準ツールのいくつかについて説明しています。

3.ダムハック（タスクがファイルシステム/ディスクアクセスでハングしていることを前提としています）

以下の詳細はばかげたハックです。時々、ばかげたハックがあなたが必要とするものです。私が言っているのは、これに頼らなければならない場合、それはあなたが整理する必要があるあなたの働き方のいくつかの欠陥を示唆するかもしれません:-P。

システムが「準応答しない」ときに実行したいシェルテストがある場合は、mlock（）されたbusyboxシェルを実行してみてください。例えば。 このLD_PRELOAD mlockハック を使用してnon静的にリンクされたbusyboxを実行します。次に、たとえばを使用してbusyboxコマンドを実行します。 (exec -a ls /proc/self/exe /)。おそらく最も安全な方法：

# prevent you running any normal program by mistake!
OLDPATH="$PATH"
PATH=

# run a busybox builtin
b() (
  local command="$1"
  shift
  exec -a "$command" /proc/self/exe "$@"
)

# run normal program in the background, in case it hangs
p() {
  local PATH="$OLDPATH"
  exec "$@" &
}

これにより、キャッシュされていないファイルを読み取ることなく、b dmesgを実行できるようになります:-)。

（これは、誰かが1）ハングしたファイルシステムをマウントするために考案した2）/または/procにマウントしたため、ハングせずに/procにアクセスすることさえできない場合に機能しなくなります。それはあまりありそうにないと思います、そしてそれを防御することはさらに苦痛でしょう。）

b ps -o stat,pid,argsはプロセスの状態を表示します。 Dは、「無停電スリープ」を意味します。通常、ディスクまたはネットワークファイルシステムを待機します。次に、b cat /proc/999/stackは、PID999がカーネルのどこで待機しているかを示します。

cd /sys/class/block/ && b grep -H . */inflightは、各ディスクの実行中の読み取りと書き込みの数を表示します。

3
sourcejedi