从不中断状态恢复系统d

Question

最近，进入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‘终端变得没有响应，然后从另一个终端登录，我可以看到新的'ps’命令被添加到'D‘进程中。

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

我还应该找什么？他们是从这里恢复过来的方法吗？

Answer 1

通常，唯一可能的恢复是重新启动--最好是通过SysRq，这样您就有机会刷新文件系统并卸载那些没有卡住的系统。不要使用sudo reboot，因为当系统等待最后一个进程完成时，它可能会挂起(这是它永远不会完成的)。

但有时还是有可能逐渐退出这个状态。在您的例子中，我将从systemd本身开始。如果您无法恢复它，那么重新启动是唯一的选择。所以试着：

$ sudo systemctl daemon-reexec

这将生成一个systemd的新副本，将当前状态交给它，并终止systemd的当前副本--希望它能解决所有的问题。这个命令可能会失败，或者像ps那样变得不可中断，或者只是无法连接到现有的systemd实例。

如果系统返回，您可以在其他守护进程上尝试类似的技巧:尝试重新启动它们。一些即使在“不间断”状态下也可能会被杀死。，试试kill -9。

堆栈跟踪特别提到了文件系统和NFS。NFS因这类问题而臭名昭著，因此考虑不要将它用于根分区等重要的事情。