วิธีตรวจสอบการใช้ดิสก์ I / O ต่อกระบวนการ


45

ฉันมีปัญหากับระบบลีนุกซ์และฉันพบ sysstat / sar เพื่อรายงานจำนวนสูงสุดของการใช้งานดิสก์ I / O, เวลาใช้งานเฉลี่ยและเวลารอคอยเฉลี่ยในช่วงที่แผงขายระบบมีปัญหา

ฉันจะพิจารณาเกี่ยวกับกระบวนการที่ทำให้จุดสูงสุดเหล่านี้เกิดขึ้นครั้งต่อไปได้อย่างไร
เป็นไปได้ที่จะทำกับ sar (เช่น: ฉันสามารถหาข้อมูลนี้จากไฟล์ sar ที่บันทึกไว้ได้หรือไม่?

เอาต์พุตสำหรับ "sar -d" แผงลอยระบบเกิดขึ้นประมาณ 12.58-13.01pm

12:40:01          DEV       tps  rd_sec/s  wr_sec/s  avgrq-sz  avgqu-sz     await     svctm     %util
12:40:01       dev8-0     11.57      0.11    710.08     61.36      0.01      0.97      0.37      0.43
12:45:01       dev8-0     13.36      0.00    972.93     72.82      0.01      1.00      0.32      0.43
12:50:01       dev8-0     13.55      0.03    616.56     45.49      0.01      0.70      0.35      0.47
12:55:01       dev8-0     13.99      0.08    917.00     65.55      0.01      0.86      0.37      0.52
13:01:02       dev8-0      6.28      0.00    400.53     63.81      0.89    141.87    141.12     88.59
13:05:01       dev8-0     22.75      0.03    932.13     40.97      0.01      0.65      0.27      0.62
13:10:01       dev8-0     13.11      0.00    634.55     48.42      0.01      0.71      0.38      0.50

นี่เป็นคำถามที่ติดตามมาที่เธรดที่ฉันเริ่มเมื่อวานนี้: จุดสูงสุดในการโหลดและบล็อกดิสก์รอฉันหวังว่ามันจะโอเคที่ฉันสร้างหัวข้อ / คำถามใหม่เกี่ยวกับเรื่องนี้เนื่องจากฉันยังไม่สามารถแก้ไขปัญหาได้


ดูเหมือนว่าปัญหาอาจน้อยกว่ากระบวนการเฉพาะและดิสก์ไม่ตอบสนองเป็นระยะ ๆ ดิสก์ทำสิ่งต่าง ๆ เหล่านี้ซึ่งในระดับระบบดูเหมือนจะเป็นหน้าผาที่ระบบชน หากคุณไม่พบผู้กระทำผิดนี่เป็นเวลาที่จะตรวจสอบระบบย่อยของดิสก์
slashdot



คำตอบ:


45

หากคุณโชคดีพอที่จะจับระยะเวลาการใช้ประโยชน์สูงสุดต่อไปคุณสามารถศึกษาต่อกระบวนการของ I / O สถิติการโต้ตอบโดยใช้iotop


เฮ้ขอบคุณ! ยังมีของเล่นอีกประเภทที่น่าเก็บไว้ในกล่องเครื่องมือของฉัน :-)
Janne Pikkarainen

การใช้ไอโซโทปในโหมดแบทช์อาจเป็นการเสริม / ทดแทนที่ดีมากสำหรับโซลูชัน "ps -eo" ด้านบน ขอบคุณ!
Avada Kedavra

2
ยอดเยี่ยม "iotop -n 1 -b -o" ให้ผลลัพธ์ที่ฉันต้องการ ขอบคุณ!
Avada Kedavra

ดูเหมือนว่าต้องใช้การเข้าถึงรูทของระบบเพื่อรัน
user5359531

29

คุณสามารถใช้pidstatเพื่อพิมพ์สถิติ io สะสมต่อกระบวนการทุก ๆ 20 วินาทีด้วยคำสั่งนี้:

# pidstat -dl 20

แต่ละแถวจะมีคอลัมน์ follwing:

  • PID - ID กระบวนการ
  • kB_rd / s - จำนวนกิโลไบต์ที่งานทำให้เกิดการอ่านจากดิสก์ต่อวินาที
  • kB_wr / s - จำนวนกิโลไบต์ที่งานเกิดขึ้นหรือจะทำให้เขียนลงดิสก์ต่อวินาที
  • kB_ccwr / s - จำนวนกิโลไบต์ที่งานเขียนไปยังดิสก์ถูกยกเลิกโดยงาน สิ่งนี้อาจเกิดขึ้นเมื่องานตัดทอน pagecache ที่สกปรก ในกรณีนี้ IO บางอย่างที่มีภารกิจอื่นเข้ามาเกี่ยวข้องจะไม่เกิดขึ้น
  • Command - ชื่อคำสั่งของภารกิจ

ผลลัพธ์มีดังนี้:

05:57:12 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:32 PM       202      0.00      2.40      0.00  jbd2/sda1-8
05:57:32 PM      3000      0.00      0.20      0.00  kdeinit4: plasma-desktop [kdeinit]              

05:57:32 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:57:52 PM       202      0.00      0.80      0.00  jbd2/sda1-8
05:57:52 PM       411      0.00      1.20      0.00  jbd2/sda3-8
05:57:52 PM      2791      0.00     37.80      1.00  kdeinit4: kdeinit4 Running...                   
05:57:52 PM      5156      0.00      0.80      0.00  /usr/lib64/chromium/chromium --password-store=kwallet --enable-threaded-compositing 
05:57:52 PM      8651     98.20      0.00      0.00  bash 

05:57:52 PM       PID   kB_rd/s   kB_wr/s kB_ccwr/s  Command
05:58:12 PM       202      0.00      0.20      0.00  jbd2/sda1-8
05:58:12 PM      3000      0.00      0.80      0.00  kdeinit4: plasma-desktop [kdeinit]              

10

ไม่มีอะไรเต้นตรวจสอบอย่างต่อเนื่องคุณก็ไม่สามารถรับข้อมูลที่ไวต่อเวลากลับมาหลังจากเหตุการณ์ ...

มีบางสิ่งที่คุณอาจตรวจสอบเพื่อมีส่วนร่วมหรือกำจัดอย่างไรก็ตาม - /procเป็นเพื่อนของคุณ

sort -n -k 10 /proc/diskstats
sort -n -k 11 /proc/diskstats

ฟิลด์ที่ 10, 11 เป็นเซกเตอร์สะสมที่เขียนและเวลาที่สะสม (มิลลิวินาที) สิ่งนี้จะแสดงพาร์ติชั่นระบบไฟล์สุดฮอตของคุณ

cut -d" " -f 1,2,42 /proc/*/stat | sort -n -k +3

ฟิลด์เหล่านั้นเป็น PID คำสั่งและเห็บ IO-wait ticks สิ่งนี้จะแสดงกระบวนการทำงานร้อนของคุณแม้ว่าจะยังทำงานอยู่ก็ตาม (คุณอาจต้องการละเว้นเธรดระบบไฟล์ของคุณ)

ประโยชน์ของข้อมูลข้างต้นขึ้นอยู่กับสถานะการออนไลน์ลักษณะของกระบวนการที่ใช้เวลานานและวิธีการใช้ระบบไฟล์ของคุณ

คำเตือน: ไม่สามารถใช้กับเมล็ดข้าวก่อน 2.6 ตรวจสอบเอกสารของคุณหากไม่แน่ใจ

(ตอนนี้ไปทำในสิ่งที่คุณต้องการในอนาคตและติดตั้ง Munin / Nagios / Cacti / Anything ;-)


10

atopใช้ ( http://www.atoptool.nl/ )

เขียนข้อมูลไปยังไฟล์บีบอัดที่atopสามารถอ่านได้ในภายหลังในสไตล์การโต้ตอบ อ่าน (เดลต้า) ทุก ๆ 10 วินาที ทำ 1080 ครั้ง (3 ชั่วโมงดังนั้นหากคุณลืมไฟล์เอาต์พุตจะไม่ทำให้ดิสก์หมด):

$ atop -a -w historical_everything.atop 10 1080 &

หลังจากสิ่งเลวร้ายเกิดขึ้นอีกครั้ง:

(แม้ว่ามันจะยังคงทำงานในพื้นหลังมันก็ต่อท้ายทุก ๆ 10 วินาที)

% atop -r historical_everything.atop

เมื่อคุณพูดถึง IO ฉันจะกดปุ่ม 3 ปุ่ม: tdD

t - move forward to the next data gathering (10 seconds)
d - show the disk io oriented information per process
D - sort the processes based on disk activity
T - go backwards 1 data point (10 seconds probably)
h - bring up help
b - jump to a time (nearest prior datapoint) - e.g. b12:00 - only jumps forward
1 - display per second instead of delta since last datapiont in the upper half of the display

4

btraceใช้ btrace /dev/sdaมันเป็นเรื่องง่ายที่จะใช้เช่น ถ้าคำสั่งไม่พร้อมใช้งานก็อาจจะมีอยู่ในแพคเกจblktrace

แก้ไข : เนื่องจาก debugfs ไม่ได้เปิดใช้งานในเคอร์เนลคุณอาจลองdate >>/tmp/wtf && ps -eo "cmd,pid,min_flt,maj_flt" >>/tmp/wtfหรือคล้ายกัน ความผิดพลาดของการบันทึกหน้าเว็บนั้นไม่เหมือนกับการใช้ btrace แต่ถ้าคุณโชคดีมันอาจให้คำแนะนำบางอย่างเกี่ยวกับกระบวนการส่วนใหญ่ของดิสก์ ฉันเพิ่งลองว่าหนึ่งในเซิร์ฟเวอร์ I / O มากที่สุดของฉันและรายการรวมถึงกระบวนการที่ฉันรู้ว่ากำลังใช้ I / O จำนวนมาก


สวัสดี Janne เคอร์เนลโชคไม่ดีที่ไม่ได้รวบรวมระบบไฟล์ debug และเป็นระบบ live ดังนั้นฉันจึงไม่สามารถคอมไพล์เคอร์เนลได้อีก มีวิธีอื่นในการทำเช่นนี้โดยไม่ต้องทำการคอมไพล์ซ้ำหรือไม่?
Avada Kedavra

ตกลงฉันแก้ไขตอบของฉันบิต :)
เจนส์ Pikkarainen

เยี่ยมมากตอนนี้เราไปถึงที่ไหนซักแห่ง! ฉันกำลังคิดเกี่ยวกับการใส่สิ่งนี้ลงใน cronjob และดำเนินการพร้อมกับงาน sar cron จากนั้นในครั้งต่อไปที่เซิร์ฟเวอร์หยุดทำงานฉันควรจะเปรียบเทียบอัตราความผิดพลาดของหน้าเว็บเพื่อดูว่ากระบวนการ / กระบวนการใดที่มีอัตราความผิดพลาดของหน้าเพิ่มขึ้น ฉันเดาว่าฉันอาจจะโชคไม่ดีและเห็นการเพิ่มขึ้นของดิสก์ io สำหรับกระบวนการทั้งหมดในคอก แต่มันคุ้มค่าที่จะลอง ขอบคุณ Janne! (ฉันจะโหวตให้ผู้ตอบคำถามของคุณถ้าทำได้: S)
Avada Kedavra

ไม่เป็นไร แจ้งให้เราทราบว่ามันไปอย่างไรนี่เป็นเพียงความพยายามแก้ปัญหาที่สร้างสรรค์จากฉัน :-)
Janne Pikkarainen

เอาต์พุตของไอโซโทปง่ายต่อการตีความดังนั้นจึงยอมรับวิธีแก้ปัญหานั้นไม่ได้ ฉันจะกลับไปลงคะแนนในคำตอบของคุณทันทีที่ฉันได้รับตัวแทนเพียงพอที่จะทำเช่นนั้น ขอบคุณสำหรับการสนับสนุน!
Avada Kedavra
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.