☰

중단되지 않은 상태에서 시스템 재개

tag-icon • tag-icon centos systemd
중단되지 않은 상태에서 시스템 재개

최근 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는 이와 같은 문제로 악명 높으므로 루트 파티션과 같은 중요한 작업에는 사용하지 않는 것이 좋습니다.

관련 정보