最近、SSHを介してCentOs8仮想マシンに接続する速度が非常に遅くなりました。 topコマンドを確認しましたが、次のように表示されます。
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 Mem
PID 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」と入力すると端末が応答しなくなり、別の端末から再度ログインすると、「D」プロセスに新しい「ps」コマンドが追加されたことがわかります。
All of the ps,grep D state process's and and systemd's stack trace:
[<0>] __access_remote_vm+0x5a/0x2d0
[<0>] proc_pid_cmdline_read+0x1a6/0x350
[<0>] vfs_read+0x91/0x140
[<0>] ksys_read+0x4f/0xb0
[<0>] do_syscall_64+0x5b/0x1b0
[<0>] entry_SYSCALL_64_after_hwframe+0x65/0xca
[<0>] 0xffffffffffffffff
khugepaged:
[<0>] collapse_huge_page+0x11f/0xdf0
[<0>] khugepaged+0xb4f/0x1140
[<0>] kthread+0x112/0x130
[<0>] ret_from_fork+0x35/0x40
[<0>] 0xffffffffffffffff
kswapd0:
[<0>] rpc_wait_bit_killable+0x1e/0x90 [sunrpc]
[<0>] _nfs4_proc_delegreturn+0x22e/0x330 [nfsv4]
[<0>] nfs4_proc_delegreturn+0x7c/0x130 [nfsv4]
[<0>] nfs_do_return_delegation+0x33/0x50 [nfsv4]
[<0>] nfs4_evict_inode+0x25/0x70 [nfsv4]
[<0>] evict+0xd2/0x1a0
[<0>] dispose_list+0x48/0x60
[<0>] prune_icache_sb+0x52/0x70
[<0>] super_cache_scan+0x123/0x1a0
[<0>] do_shrink_slab+0x118/0x270
[<0>] shrink_slab+0x187/0x2e0
[<0>] shrink_node+0xe4/0x440
[<0>] balance_pgdat+0x1e2/0x340
[<0>] kswapd+0x21a/0x400
[<0>] kthread+0x112/0x130
[<0>] ret_from_fork+0x35/0x40
[<0>] 0xffffffffffffffff
[<0>] prealloc_shrinker+0x6d/0x110
systemd-user-ru:
[<0>] sget_userns+0x2c0/0x4b0
[<0>] mount_nodev+0x2a/0xa0
[<0>] mount_fs+0x3b/0x167
[<0>] vfs_kern_mount.part.35+0x54/0x120
[<0>] do_mount+0x1fc/0xc80
[<0>] ksys_mount+0xb6/0xd0
[<0>] __x64_sys_mount+0x21/0x30
[<0>] do_syscall_64+0x5b/0x1b0
[<0>] entry_SYSCALL_64_after_hwframe+0x65/0xca
[<0>] 0xffffffffffffffff
また何を探すべきですか？これが彼らがこの状況で回復する方法ですか？
答え1
通常、可能な唯一の回復方法は再起動です。可能であれば、SysRqを使用してファイルシステムを更新し、中断されていないシステムをアンマウントできます。するいいえ sudo rebootこれは、システムが最後のプロセスが完了するのを待っている間に中断される可能性があるためです（決してそうではありません）。
しかし、時にはこの状態を徐々に終了することが可能です。あなたの場合はsystemd自体から始めます。回復が不可能な場合は、再起動のみが唯一の方法です。だから試してみてください：
$ sudo systemctl daemon-reexec
これにより、systemdの新しいコピーがフォークされ、現在の状態が渡され、systemdの現在のコピーが終了します。問題が解決することを願っています。このコマンドは、ps以前と同じように中断できなくなったり、既存のシステムインスタンスに接続できなくなったりして失敗する可能性があります。
systemdを復元した場合は、他のデーモンでも同様の方法を試すことができます。つまり、再起動してみてください。一部「無妨害」の状態でも死亡可能、努力するkill -9。
スタックトレースでは、ファイルシステムとNFSが具体的に言及されています。 NFSはこのような問題で悪名高いので、ルートパーティションなどの重要な操作には使用しないことをお勧めします。