Score:0

กระบวนการบางอย่างอยู่ในสถานะสลีปที่ไม่สามารถกำจัดได้ในขณะที่ i/o ต่ำ

ธง es

ฉันเป็นผู้ดูแลระบบของเวิร์กสเตชันที่ใช้ Arch Linux เวิร์กสเตชันของเราใช้ Slurm เป็นตัวจัดการโหลดและประกอบด้วยเครื่องหลักหนึ่งเครื่องและโหนดการคำนวณอื่นๆ อีก 4 โหนด ในช่วงไม่กี่เดือนที่ผ่านมา เราสังเกตเห็นว่ากระบวนการในบางโหนดติดขัดเป็นครั้งคราว และการรีบูตโหนดจะช่วยแก้ปัญหาได้ เราพบว่ากระบวนการที่ค้างอยู่ในสถานะ D (ดิสก์อยู่ในโหมดสลีป) แต่เมื่อเราใช้คำสั่งบนสุดหรือคำสั่งอื่นๆ เพื่อตรวจสอบ i/o ของโหนด เราพบว่าในความเป็นจริงแล้ว i/o ค่อนข้างต่ำ

เมื่อกระบวนการบางอย่างบนโหนดอยู่ในสถานะ D ทุกอย่างบนโหนดจะช้า แต่สำหรับผู้ใช้ปกติเท่านั้น เมื่อเราใช้ superuser เพื่อเรียกใช้คำสั่ง (รวมถึง python) บนโหนดที่ติดอยู่ ทุกอย่างทำงานได้ดี แต่เมื่อเราเปลี่ยนผู้ใช้โดย su NORMAL_USERกระบวนการติดอยู่อีกครั้ง เราใช้ ps aux และพบว่ากระบวนการ -ทุบตี เรียกใช้โดย NORMAL_USER อยู่ในสถานะ D เราได้พยายามใช้ สเตรส เพื่อติดตามกระบวนการที่ติดอยู่ และเราได้เจาะลึกลงไปใน /proc/PIDแต่เราไม่พบสิ่งที่เป็นประโยชน์ เรายังไม่พบข้อความที่เป็นประโยชน์จาก วารสาร ctl. บางทีเราอาจจะขาดอะไรไป เรายินดีน้อมรับคำแนะนำหรือติชม

เวอร์ชันเคอร์เนลของเราคือ 5.10.47-1-lts

ที่นี่คือ /proc/PID/สถานะ สำหรับกระบวนการในสถานะ D. กระบวนการคือ the ทุบตี กระบวนการเมื่อเราใช้ su NORMAL_USER. เป็นกระบวนการเธรดเดียว

ชื่อ: บาส
ยูมาสค์: 0022
สถานะ: D (ดิสก์สลีป)
รหัส: 3136723
งิด: 0
รหัส: 3136723
PPid: 3136722
เทรเซอร์พิด: 0
รหัส: 1000093 1000093 1000093 1000093
รหัส: 1000000 1000000 1000000 1000000
FDขนาด: 256
กลุ่ม: 1000000 1000083
NStgid: 3136723
NSpid: 3136723
NSpgid: 3136723
หมายเลขรหัส: 3110369
VmPeak: 16904 กิโลไบต์
ขนาด Vm: 16904 กิโลไบต์
VmLck: 0 กิโลไบต์
VmPin: 0 กิโลไบต์
VmHWM: 3788 กิโลไบต์
VmRSS: 3744 กิโลไบต์
RSSอานนท์: 412 kB
ไฟล์ Rss: 3332 กิโลไบต์
RssShmem: 0 กิโลไบต์
VmData: 608 กิโลไบต์
VmStk: 132 กิโลไบต์
VmExe: 588 กิโลไบต์
VmLib: 1948 กิโลไบต์
VmPTE: 52 กิโลไบต์
VmSwap: 0 กิโลไบต์
Hugetlbหน้า: 0 kB
การทุ่มตลาดหลัก: 0
THP_enabled: 1
หัวข้อ: 1
ซิกคิว: 12/772094
SigPnd: 0000000000000000
ShdPnd: 0000000008000002
SigBlk: 0000000000000000
เครื่องหมาย: 0000000000384004
SigCgt: 000000004b813efb
แคปอินห์: 0000000000000000
CapPrem: 0000000000000000
ความจุสูงสุด: 0000000000000000
CapBnd: 000001ffffffffff
แคปแอม: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Seccomp_filters: 0
Speculation_Store_Bypass: เธรดมีช่องโหว่
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/สแต็ค สำหรับกระบวนการเดียวกัน

[<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
jp flag
กระบวนการที่ติดอยู่บน NFS สามารถถูกฆ่าได้ด้วยสัญญาณ SIGKILL (ฆ่า -9)
David Chiang avatar
es flag
@AlexD ฉันพยายามฆ่ากระบวนการเหล่านั้นและแน่นอนว่าพวกเขาสามารถถูกฆ่าได้! ขอขอบคุณ! คุณนึกถึงสาเหตุใดที่ทำให้กระบวนการค้างอยู่ใน NFS เครือข่ายระหว่างโหนดการคำนวณและ NFS ทำงานตามปกติ และเราไม่พบข้อความแสดงข้อผิดพลาดใดๆ ที่บ่นเกี่ยวกับ NFS ใน `journalctl`
Michael Hampton avatar
cz flag
เหตุใดโหนดจึงไม่ทันสมัย
David Chiang avatar
es flag
@MichaelHampton คุณหมายถึงเวอร์ชันของเคอร์เนลหรือไม่
David Chiang avatar
es flag
เราพบว่ากระบวนการที่ติดอยู่บน NFS อาจเกิดจากข้อโต้แย้งที่เราเขียนใน `/etc/fstab` เราใช้พารามิเตอร์เริ่มต้น และเราคิดว่าปัญหาของเราอาจแก้ไขได้หากเราระบุ `fsc` (ค่าเริ่มต้นคือ `nofsc`) เราจะอัปเดตคำถามหากสามารถแก้ปัญหาได้ ขอบคุณทุกคน!
David Chiang avatar
es flag
หลังจากที่เราเปลี่ยนพารามิเตอร์การติดตั้ง NFS ปัญหายังคงอยู่

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา