เวลาดำเนินการคำสั่งช้าใน linux

เราพบกับคำสั่งช้า ๆ ใน Linux ซึ่งอาจเกี่ยวข้องกับ procfs slowness

เหมือนง่าย ๆ uptime คำสั่งอาจใช้เวลาสองสามวินาทีในการดำเนินการ

นี่คืออินพุต:

• แพลตฟอร์ม: AWS
• อินสแตนซ์: x1.32xl (128 คอร์พร้อม RAM 2T)
• ระบบปฏิบัติการ: Ubuntu 16.04
• เคอร์เนล: 4.4.0-1043-aws

เราใช้นักเทียบท่ากับตู้คอนเทนเนอร์ประมาณ 250 ตู้

• รุ่นนักเทียบท่า: 17.09-ce

การใช้ประโยชน์:

• การใช้ CPU: & lt; 50%
• การใช้หน่วยความจำ: & lt; 50%

สถิติระบบปฏิบัติการบางอย่าง:

# cat /proc/loadavg
100.45 108.30 109.41 35/254951 544357

# vmstat 1 3
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
110  2 791584 485552640 50354496 687472448    0    0   426   183    1    1 10  8 82  1  0
13  0 791584 485495104 50353940 687477568    0    0 22820 47984 196555 326943 12 12 75  1  0
33  1 791584 485385632 50352428 687473536    0    0 38932 52892 166486 389428 13 14 72  1  0

# ps axu| wc -l
3792

เกิดอะไรขึ้นกันแน่?

การเรียกใช้คำสั่งง่าย ๆ ต้องใช้เวลาเมื่อคำสั่งใช้ procfs ในทางใดทางหนึ่ง ชอบทำ ls ใน dir ที่มีไฟล์จำนวนมากติดค้างอยู่บน syscall ของ procfs

# strace -r ls
...
0.000084 open("/proc/filesystems", O_RDONLY) = 3
3.652504 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
...

หรือ uptime:

# strace -r uptime
...
0.000035 open("/proc/filesystems", O_RDONLY) = 3
11.014154 fstat(3, {st_mode=S_IFREG|0444, st_size=0, ...}) = 0
...
0.000044 open("/proc/uptime", O_RDONLY) = 3
1.554646 lseek(3, 0, SEEK_SET)
...

Quick Q / A และสิ่งที่เราได้ลองไปแล้ว:

• ความเชื่องช้านี้มีอยู่ในระดับโฮสต์เท่านั้น ในตู้คอนเทนเนอร์เราไม่เห็นปัญหาดังกล่าว เราเล่นไปรอบ ๆ และดูปัญหานี้เมื่อเราเรียกใช้คอนเทนเนอร์ด้วย ทั้งสอง --ipc=host และ --pid=host ธง
• เราได้ติดตามความเชื่องช้านี้ใน procfs เพื่อ mutex_lock ที่นี่ https://github.com/torvalds/linux/blob/v4.4/fs/namei.c#L3082
• ภาชนะมากเกินไป
  • ไม่เรามี 600 บนโฮสต์อื่นและดีทั้งหมด
• มีกระบวนการมากเกินไป
  • ไม่เรามี 10K บนโฮสต์อื่นและดีทั้งหมด
• มีเธรดมากเกินไป
  • นั่นอาจเป็น เราไม่มีจำนวนเธรดในโฮสต์อื่น ๆ แต่เราพยายามทำซ้ำบนอินสแตนซ์ที่สะอาด x1.32x ขนาดใหญ่และล้มเหลว ดังนั้นมันอาจเป็น treads + smth อย่างอื่น

ยินดีต้อนรับความคิดและคำแนะนำใด ๆ