Sunt administratorul de sistem al unei stații de lucru bazate pe Arch Linux. Stația noastră de lucru folosește Slurm ca manager de încărcare și constă dintr-o mașină principală și alte 4 noduri de calcul. În ultimele luni, observăm că procesele de pe unele noduri sunt blocate din când în când, iar repornirea nodului rezolvă problema. Am descoperit că procesele blocate sunt în starea D (disc sleeping), dar când folosim comenzi de sus sau alte comenzi pentru a verifica i/o nodului, am constatat că i/o este de fapt destul de scăzut.
Când unele procese de pe nod sunt în starea D, totul pe nod este lent, dar acest lucru este doar pentru utilizatorii normali. Când folosim superutilizator pentru a rula comenzi (inclusiv python) pe nodurile blocate, totul funcționează bine. Dar când schimbăm utilizatorul prin su NORMAL_USER, procesul este din nou blocat. Noi am folosit ps aux și a constatat că procesul -bash rulat de NORMAL_USER este în starea D. Am încercat să folosim strace pentru a urmări procesul blocat, și am săpa, de asemenea, în /proc/PID, dar nu am reușit să găsim nimic util. De asemenea, nu am reușit să identificăm niciun mesaj utile de la jurnalctl. Poate ne lipsește ceva.
Suntem dispuși să primim orice sfat sau comentariu.
Versiunea noastră de kernel este 5.10.47-1-lts.
Aici este /proc/PID/status pentru procesul în starea D. Procesul este cel bash proces atunci când folosim su NORMAL_USER. Este un proces cu un singur fir.
Nume: bash
Umask: 0022
Stare: D (repaus disc)
Tgid: 3136723
Ngid: 0
Cod: 3136723
PPid: 3136722
TracerPid: 0
Uid: 1000093 1000093 1000093 1000093
Gid: 1000000 1000000 1000000 1000000
Dimensiune FDS: 256
Grupuri: 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
Fișier RSS: 3332 kB
RssShmem: 0 kB
VmData: 608 kB
VmStk: 132 kB
VmExe: 588 kB
VmLib: 1948 kB
VmPTE: 52 kB
VmSwap: 0 kB
HugetlbPagini: 0 kB
CoreDumping: 0
THP_activat: 1
Fire: 1
SigQ: 12/772094
SigPnd: 0000000000000000
ShdPnd: 0000000008000002
SigBlk: 0000000000000000
Semn: 0000000000384004
SigCgt: 000000004b813efb
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 000001ffffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: fire vulnerabile
Procesor_permis: ffff,ffffffff
Lista_permise_procesoare: 0-47
Mems_allowed: 00000003
Listă_permise_Mems: 0-1
voluntary_ctxt_switches: 4
comutatoare_ctxt_nonvoluntary: 1
Aici este /proc/PID/stack pentru acelasi proces.
[<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
