我是一个基于 Arch Linux 的工作站的系统管理员。我们的工作站使用 Slurm 作为负载管理器，由一台主机和另外 4 个计算节点组成。在过去的几个月里，我们观察到某些节点上的进程不时卡住，重新启动节点可以解决问题。我们发现卡住的进程处于状态 D（磁盘休眠），但当我们使用 top 或其他命令检查节点的 i/o 时，我们发现 i/o 实际上相当低。
当节点上的某些进程处于状态 D 时，节点上的所有进程都会变慢，但这仅对普通用户而言。当我们使用超级用户在卡住的节点上运行命令（包括 python）时，一切都会正常工作。但是当我们将用户更改为 时su NORMAL_USER，进程再次卡住。我们使用ps aux发现-bashNORMAL_USER 运行的进程处于状态 D。我们曾尝试使用strace来跟踪卡住的进程，我们也深入研究了/proc/PID，但没有找到任何有用的东西。我们也未能从 中识别出任何有用的消息journalctl。也许我们遗漏了一些东西。我们愿意接受任何建议或意见。
我们的内核版本是5.10.47-1-lts。
这是/proc/PID/statusD 状态进程的 。 该进程是bash我们使用 时的进程su NORMAL_USER。它是一个单线程进程。
Name: bash
Umask: 0022
State: D (disk sleep)
Tgid: 3136723
Ngid: 0
Pid: 3136723
PPid: 3136722
TracerPid: 0
Uid: 1000093 1000093 1000093 1000093
Gid: 1000000 1000000 1000000 1000000
FDSize: 256
Groups: 1000000 1000083
NStgid: 3136723
NSpid: 3136723
NSpgid: 3136723
NSsid: 3110369
VmPeak: 16904 kB
VmSize: 16904 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 3788 kB
VmRSS: 3744 kB
RssAnon: 412 kB
RssFile: 3332 kB
RssShmem: 0 kB
VmData: 608 kB
VmStk: 132 kB
VmExe: 588 kB
VmLib: 1948 kB
VmPTE: 52 kB
VmSwap: 0 kB
HugetlbPages: 0 kB
CoreDumping: 0
THP_enabled: 1
Threads: 1
SigQ: 12/772094
SigPnd: 0000000000000000
ShdPnd: 0000000008000002
SigBlk: 0000000000000000
SigIgn: 0000000000384004
SigCgt: 000000004b813efb
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: thread vulnerable
Cpus_allowed: ffff,ffffffff
Cpus_allowed_list: 0-47
Mems_allowed: 00000003
Mems_allowed_list: 0-1
voluntary_ctxt_switches: 4
nonvoluntary_ctxt_switches: 1
以下是/proc/PID/stack同一过程。
[<0>] nfs_wait_bit_killable+0x1e/0x90 [nfs]
[<0>] nfs4_wait_clnt_recover+0x60/0x90 [nfsv4]
[<0>] nfs4_client_recover_expired_lease+0x17/0x50 [nfsv4]
[<0>] nfs4_do_open+0x2f4/0xbe0 [nfsv4]
[<0>] nfs4_atomic_open+0xe7/0x100 [nfsv4]
[<0>] nfs_atomic_open+0x1e1/0x520 [nfs]
[<0>] path_openat+0x5f5/0xfc0
[<0>] do_filp_open+0x91/0x130
[<0>] do_sys_openat2+0x96/0x150
[<0>] __x64_sys_openat+0x53/0x90
[<0>] do_syscall_64+0x33/0x40
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xa9