CentOs8 systemd 割り込みできないスリープ状態 D Stateで load averageが増加する事象に関する情報です。
最近、CentOs8 VM への ssh 接続が非常に遅くなりました。これを示すトップコマンドを確認しました。
load average: 30.09, 30.13, 30.09
Tasks: 403 total, 1 running, 364 sleeping, 0 stopped, 38 zombie
%Cpu(s): 2.4 us, 1.1 sy, 0.0 ni, 94.9 id, 0.0 wa, 1.4 hi, 0.2 si, 0.0 st
MiB Mem : 15853.6 total, 5322.0 free, 8791.9 used, 1739.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 6052.8 avail MemPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 20 0 245460 8192 4132 D 0.0 0.1 662:05.04 systemd
43 root 39 19 0 0 0 D 0.0 0.0 15:06.70 khugepaged
56 root 20 0 0 0 0 D 0.0 0.0 68:38.87 kswapd0
34809 root 20 0 0 0 0 D 0.0 0.0 0:00.09 sh
41031 101 20 0 34248 25884 4 D 0.0 0.2 0:00.62 nginx
41309 root 20 0 93260 6740 5904 D 0.0 0.0 0:00.03 systemd-user-ru
44308 root 20 0 57184 3760 3340 D 0.0 0.0 0:00.01 ps
...etc
ps、pgrep などの他のコマンドは、使用するとすぐに「D」状態になります。したがって、「ps aux」と入力すると、端末が応答しなくなり、他の端末からログオンし直すと、新しい「ps」コマンドが「D」プロセスに追加されていることがわかります。
一般に、可能な唯一の回復方法は再起動です。できれば SysRq を使用して、ファイル システムをフラッシュし、スタックしていないファイル システムをアンマウントする機会を得ることができます。システムが最後のプロセスが完了するのを待っている間にハングする可能性があるため、行わないでください (これは決して完了しません) 。sudo reboot
ただし、この状態から徐々に回復できる場合もあります。あなたの場合は、systemd 自体から始めます。回復できない場合は、再起動が唯一の選択肢です。それで試してみてください:
$ sudo systemctl daemon-reexec
これにより、systemd の新しいコピーがフォークされ、現在の状態が渡され、systemd の現在のコピーが終了します。これですべての問題が解決されると思います。このコマンドは、中断不能になるかps、既存の systemd インスタンスへの接続に失敗するだけで失敗する可能性があります。
systemd が戻ったら、他のデーモンでも同様のトリックを試すことができます。つまり、デーモンを再起動してみてください。いくつかは「中断不可能」状態でも強制終了できるかもしれません。試してみてくださいkill -9。
スタックトレースでは、特にファイルシステムと NFS について言及しています。NFS はこの種の問題でよく知られているため、ルート パーティションなどの重要なものには NFS を使用しないことを検討してください。
「参考」
centos - Recover systemd from uninterruptible state - Unix & Linux Stack Exchange
 |
