การรอคอย High IO - วิธีการตรวจสอบสาเหตุที่แท้จริง?


10

ฉันมีอินสแตนซ์ MySQL บนเซิร์ฟเวอร์เฉพาะสองแห่ง หนึ่งสำหรับการผลิตอีกหนึ่งสำหรับแพลตฟอร์มการทดสอบ

เซิร์ฟเวอร์ 2 ตัวค่อนข้างเหมือนกันความแตกต่างเพียงอย่างเดียวคือตัวควบคุม RAID และปริมาณเสมือน (HD เหมือนกัน) ในการผลิตมีคอนโทรลเลอร์ HW RAID เฉพาะและโวลุ่ม RAID 10 ในอีกด้านหนึ่งคอนโทรลเลอร์ RAID ดูเหมือนจะเป็นซอฟต์แวร์ (Lenovo ThinkServer RAID 110i) และโวลุ่มนั้นคือ RAID 5

เราสังเกตเห็นว่าระหว่างการคอมมิชชัน MySQL เรามีไอโออิทสูง:

while true; do date; ps auxf | awk '{if($8=="D") print $0;}'; sleep 1; done
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:37 CEST 2015
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:38 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root     26691  0.0  0.0      0     0 ?        D    Jun09   0:57  \_ [jbd2/dm-10-8]
Thu Jun 18 13:49:39 CEST 2015
Thu Jun 18 13:49:40 CEST 2015
root      1474  0.0  0.0      0     0 ?        D    Jun04   0:23  \_ [jbd2/dm-5-8]
root      1478  0.0  0.0      0     0 ?        D    Jun04   0:03  \_ [jbd2/dm-7-8]
root     26661  0.0  0.0      0     0 ?        D    Jun09   5:41  \_ [jbd2/dm-14-8]

dm-10-8 & dm-14-8 เกี่ยวข้องกับพาร์ติชันฐานข้อมูล

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  3 240904 809656 572624 7114416    0    0    59  1681 2002 5141  3  1 67 30  0
 0  4 240880 809656 572632 7114604    0    0   139  2069 2090 4985  3  1 67 29  0
 1  2 240880 809284 572636 7114676    0    0    27  2159 2253 4247  2  1 72 25  0
 5  2 240880 809408 572656 7114820    0    0    27  2404 2254 5350  3  1 69 27  0

ฉันสงสัยว่าคอนโทรลเลอร์ควบคุมฉันจะแน่ใจได้อย่างไร


อาจปิดหัวข้อ: แต่ทำไม RAID5 บนฐานข้อมูล แนวคิดที่ไม่ดีเนื่องจากช่องว่างการเขียน HW กับ BBU ช่วยลดสิ่งนี้ได้บ้าง แต่ RAID 5 นั้นดีสำหรับการอ่านไม่ใช่การเขียนธุรกรรมขนาดเล็ก
Hennes

เพราะฉันไม่มีทางเลือก ... RAID 10 ไม่รองรับตัวควบคุม RAID นี้ (ด้วยรุ่น RHEL ของฉัน) ...
Bob Sauvage

@BobSauvage ความคืบหน้าใด ๆ
Huygens

เพื่อให้ชัดเจน: การรวม io-wait รวมทั้งรอให้ไฟล์ descriptors ที่ไม่ได้ถูกจัดเก็บโดยที่เก็บข้อมูลขนาดใหญ่หรือไม่ เหมือนซ็อกเก็ต ...
มัสซิโม

คำตอบ:


7

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

การตรวจสอบฮาร์ดแวร์

ฉันเข้าใจว่าสำหรับแอปพลิเคชันเดียวกัน แต่ในชุดฮาร์ดแวร์ 2 ชุดประสิทธิภาพแตกต่างกันมากและคุณต้องการที่จะเข้าใจว่าทำไม ดังนั้นฉันจึงเสนอวิธีแรกที่จะช่วยคุณค้นหาคำตอบสำหรับ "ทำไม"

เพื่อประสิทธิภาพฉันมักจะอ้างถึงLinux Performance Map ที่จัดทำโดย Brendan Gregg ในบล็อกของเขา จะเห็นได้ว่าในระดับต่ำ (ใกล้เคียงกับฮาร์ดแวร์) เครื่องมืออย่างblktraceสมบูรณ์แบบ

ไม่ทราบเครื่องมือนี้จริงๆฉันค้นหารอบ ๆ และพบบทความที่น่าสนใจเกี่ยวกับ blktraceโดย Marc Brooker โดยทั่วไปจะแนะนำต่อไปนี้การดำเนินการ I / O ร่องรอยการใช้blktrace; ใช้เครื่องมือbttเพื่อดึงข้อมูลจากการติดตามนี้ นั่นจะเป็นสิ่งนี้ (สำหรับการติดตาม 30 วินาที):

# blktrace -w 30 -d /dev/dm-10-8 -o dm-10-8
# blkparse -d blkmerged.out dm-10-8*
# btt -i blkmerged.out | less

การส่งออกอาจจะค่อนข้างยาว แต่มองหารายการ D2C มันจะช่วยให้คุณทราบเวลาที่ใช้สำหรับ I / O ที่ส่งไปยังไดรเวอร์อุปกรณ์ที่จะรายงานว่าเสร็จสมบูรณ์โดยไดรเวอร์นี้

ตัวอย่างผลลัพธ์ ( dnf upgradeทำงานบน VirtualBox VM บนแล็ปท็อปไม่ว่างของฉัน):

            ALL           MIN           AVG           MAX           N
--------------- ------------- ------------- ------------- -----------

...
D2C               0.000046515   0.045781696   3.940577359       11713
...

มันแสดงค่าเฉลี่ยที่น่าผิดหวัง 45 มิลลิวินาทีต่อ I / O และสูงถึง 3,94 วินาทีสำหรับกรณีที่เลวร้ายที่สุด !!

สำหรับวิธีเพิ่มเติมในการใช้ blktrace เพื่อทำการตรวจสอบนี้อ่านบทความจาก Marc Brooker ซึ่งเป็นคำแนะนำที่ดีมาก


โพสต์บล็อกของ Percona อ้างอิงในคำตอบที่ได้รับการปรับแต่งเพื่อปรับปรุงประสิทธิภาพของ Innodbได้รับการอัปเดตด้วย: อัปเดต: อย่าทำเช่นนี้ได้รับการพิสูจน์แล้วว่าข้อมูลเสียหาย!
vkats

@ vkats ขอบคุณมาก ฉันได้อัปเดตคำตอบเพื่อลบคำแนะนำและบทความแล้ว
Huygens

1

กระบวนการ jbd2 สำหรับการทำเจอร์นัล ext4 มันเป็นเหตุผลที่ระบบไฟล์จำเป็นต้องเขียนลงในสมุดรายวันในช่วง mysql นี้ไม่ควรมีเหตุผลสำหรับความกังวลใด ๆ ปริมาณของโหลดที่เกิดจาก jbd ได้รับอิทธิพลจากพารามิเตอร์ mount ของคุณสำหรับพาร์ติชัน dm-10-8 และ dm-14-8 อาจเป็นที่ต้องการที่จะมีการทำเจอร์นัลอย่างระมัดระวังที่พาร์ติชันฐานข้อมูลเพื่อให้แน่ใจว่าฐานข้อมูลของคุณไม่ได้รับความเสียหายหากมีสิ่งใดเกิดขึ้นและเซิร์ฟเวอร์ของคุณรีบูตโดยไม่ตั้งใจ คุณสามารถเลือกตัวเลือกการเมานต์เจอร์นัลอื่นในสภาพแวดล้อมการทดสอบเพื่อการเปรียบเทียบ


jbd2 / dm-2-8 ของฉันดูเหมือนตลอดเวลาประมาณ 8.5% ที่ iotop แต่ .. ฉันไม่คิดว่าเป็นปัญหาเนื่องจากไม่มีการอ่านดิสก์และการเขียนดิสก์ทั้งหมดคือ 35mb หลังจาก 1 ชั่วโมง btw, ที่ / dev มีมากที่สุด dm-2 (นั่น -8 ฉันไม่รู้ว่ามันมาจากไหน .. )
Aquarius Power
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.