การดีบัก Linux I / O latency

ฉันมีปัญหา I / O บางอย่างในระบบ Linux ที่ฉันดูแลอยู่ พวกเขาแสดงให้เห็นในกระบวนการที่มักจะบล็อกนานถึงหลายวินาทีใน syscalls ง่าย ๆ เช่น open (), ยกเลิกการเชื่อมโยง () หรือปิด () ในไฟล์ (ซึ่งเป็นปัญหาเนื่องจากโปรแกรมที่เกี่ยวข้องบางโปรแกรมต้องการเวลาแฝง I / O ค่อนข้างต่ำ อย่างถูกต้อง) มันเป็นความจริงที่ระบบที่มีปัญหาจะได้รับการโหลด I / O ปานกลาง แต่ฉันแทบจะไม่สามารถคิดได้ว่ามันจะเพียงพอที่จะพิสูจน์เวลาแฝงอันมหาศาลนี้ บางครั้งการโทรอาจใช้เวลามากกว่า 15 วินาทีในการดำเนินการให้เสร็จสมบูรณ์ (แม้ว่าบ่อยครั้งขึ้นพวกเขาอาจใช้เวลา 1 หรือ 2 หรือ 3 วินาทีหรือมากกว่านั้น)

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

อีกทางเลือกหนึ่งของแน่นอนถ้าคุณมีเงื่อนงำใด ๆ ที่เป็นสิ่งที่จริงเป็นสิ่งที่เกิดขึ้นว่าสามารถที่จะหลีกเลี่ยง?

สำหรับบันทึกระบบไฟล์ที่ฉันใช้คือ XFS

ในเวลาที่กำหนดฉันจัดการเพื่อแก้ไขปัญหานี้ด้วยตัวเองดังนั้นอย่างน้อยฉันจึงสามารถติดตามด้วยตนเองเพื่อลูกหลาน

น่าเสียดายที่ฉันสูญเสียปัญหาดั้งเดิมในการอัปเกรดเคอร์เนล แต่ได้รับการอัปเกรดใหม่แทนยิ่งประสิทธิภาพแย่ลงและยากที่จะติดตาม เทคนิคที่ฉันพบมีดังต่อไปนี้:

ก่อนอื่นblktrace/ blkparseเป็นเครื่องมือที่ฉันคิดว่าค่อนข้างมีประโยชน์ อนุญาตให้ติดตามความคืบหน้าของคำขอ I / O แต่ละรายการที่มีรายละเอียดที่เป็นประโยชน์มากมายเช่นกระบวนการที่ส่งคำขอ มันจะมีประโยชน์ในการใส่เอาท์พุทtmpfsเพื่อให้การจัดการการจัดเก็บการติดตามไม่เริ่มติดตามตัวเอง

ที่ช่วยจนถึงเท่านั้นดังนั้นฉันรวบรวมเคอร์เนลที่มีฟังก์ชันการดีบักเพิ่มเติม โดยเฉพาะฉันพบว่าftraceมีประโยชน์มากเพราะอนุญาตให้ฉันติดตามกระบวนการทำงานที่ไม่ดีภายในพื้นที่เคอร์เนลเพื่อดูว่ามันทำอะไรและบล็อกที่ไหน การคอมไพล์เคอร์เนลการดีบักยังให้WCHANเอาต์พุตการทำงานด้วยpsเช่นกันซึ่งสามารถทำงานเป็นวิธีที่ง่ายขึ้นเพื่อดูว่ากระบวนการทำอะไรอยู่ภายในเคอร์เนลอย่างน้อยก็สำหรับกรณีที่ง่ายกว่า

ฉันก็หวังว่าLatencyTopจะมีประโยชน์ แต่ฉันก็พบว่ามันค่อนข้างบั๊กและมันก็แสดงเหตุผลที่แฝงอยู่ซึ่งเป็น "ระดับสูง" เกินไปที่จะมีประโยชน์อย่างแท้จริงโชคไม่ดี

นอกจากนี้ฉันพบว่ามันมีประโยชน์มากกว่าที่iostatจะเพียงแค่ดูเนื้อหา/sys/block/$DEVICE/statในช่วงเวลาที่ใกล้มาก ๆ เช่นนี้:

while :; do cat /sys/block/sda/stat; sleep .1; done

ดูDocumentation/iostats.txtในแผนผังซอร์สเคอร์เนลสำหรับรูปแบบของstatไฟล์ การดูเป็นระยะ ๆ ช่วยให้ฉันเห็นเวลาและขนาดที่แน่นอนของ I / O burst และสิ่งต่าง ๆ

ในท้ายที่สุดฉันพบว่าปัญหาที่ฉันมีหลังจากการอัพเกรดเคอร์เนลเกิดจากหน้าเว็บที่มีความเสถียรคุณลักษณะที่นำมาใช้ใน Linux 3.0 ทำให้ในกรณีของฉัน Berkeley DB จะหยุดเป็นระยะเวลานานเมื่อหน้าสกปรกใน mmap'ed ไฟล์ภูมิภาค แม้ว่ามันจะเป็นไปได้ที่จะแก้ไขฟีเจอร์นี้และปัญหาที่อาจเกิดขึ้นได้รับการแก้ไขใน Linux 3.9 แต่ฉันได้แก้ไขปัญหาที่เลวร้ายที่สุดที่ฉันมีในตอนนี้ด้วยการแพตช์ Berkeley DBเพื่อให้ฉันใส่ไฟล์ภูมิภาคในไดเรกทอรีอื่น (ในกรณีของฉัน/dev/shm) ทำให้ฉันสามารถหลีกเลี่ยงปัญหาทั้งหมดได้

จากประสบการณ์ของฉันเครื่องมือทางสถิติที่ง่ายที่สุดและละเอียดที่สุดที่คุณสามารถติดตั้งเพื่อติดตามปัญหาประสิทธิภาพของระบบลึกลับคือhttp://freecode.com/projects/sysstat aka sar

แน่นอนว่าคุณต้องการดูเอาต์พุตคำสั่ง iostat ด้วยโดยเฉพาะ% iowait ของคุณควรต่ำกว่า 5-10% ภายใต้การโหลดระบบปกติ (ต่ำกว่า 1.0 หรือมากกว่านั้น)

ดูที่เอาต์พุต ps หากในคอลัมน์สถานะคุณเห็นสถานะ D ซึ่งหมายความว่ากระบวนการเหล่านั้นถูกล็อคและรอ IO อาจเป็นปัญหาฮาร์ดแวร์ของคอนโทรลเลอร์หรือดิสก์ตรวจสอบสถานะ SMART รวมถึง dmesg และ syslog เพื่อหาเบาะแส

ตรวจสอบ sar log และระบุเวลาสูงสุดหากเคยเกิดเหตุการณ์นี้ขึ้นและพยายามจับคู่เวลาเหล่านั้นกับงาน cron ที่ใช้ดิสก์มากเช่นการสำรองข้อมูลผ่านเครือข่าย

คุณสามารถกำหนดมาตรฐานประสิทธิภาพของดิสก์ด้วย bonnie ++

คิดว่าฉันจะพูดถึง strace แม้ว่าคำถามนี้จะมีอายุหลายเดือนแล้ว อาจช่วยคนที่มีปัญหาคล้ายกันซึ่งพบหน้านี้

ลอง.

strace "application"

คุณสามารถทำได้

strace -e read,write "application"

เพียงแสดงเหตุการณ์การอ่าน / เขียน

แอปพลิเคชันจะโหลดตามปกติ (แม้ว่าจะช้าลงเล็กน้อยในการเปิดใช้งาน) และคุณสามารถใช้งานได้ตามปกติเพื่อเปิดใช้งานปัญหา เอาต์พุตจะปรากฏในเชลล์ที่คุณใช้เพื่อเรียกใช้ strace

ข้อดีของ strace คือคุณสามารถเห็นการเรียกใช้ฟังก์ชัน / เคอร์เนลล่าสุด ณ เวลาที่แอปพลิเคชันทริกเกอร์การชะลอตัว คุณอาจพบว่าหาก/homeบัญชีของคุณอยู่ใน NFS แอปพลิเคชันจะประสบปัญหากับไฟล์ I / O ผ่าน NFS ด้วยเหตุผลบางประการ