IO Wait ก่อให้เกิดการชะลอตัวมาก (EXT4 JDB2 ที่ 99% IO) ในระหว่าง Mysql Commit

ฉันกำลังเขียนตัวทำดัชนีโดยใช้ python ซึ่งทำดัชนีเอกสารและแทรกลงในฐานข้อมูลก่อนที่มันจะเป็นกระบวนการเดียว แต่ตอนนี้ฉันทำมันเพื่อการประมวลผลแบบมัลติโพรเซสที่มี 4 กระบวนการแบบขนานที่ทำงานอยู่

ตอนนี้มันกดปุ่มปัญหา IO ปัญหา IO หลักไม่ใช่กระบวนการของฉัน แต่เป็น jdb2 ของ jtt2 ระบบ journeling ของ EXT4 มันอยู่ที่ 99.99% และใช้ CPU ในการรอให้ IO อยู่ใน MySQL Commit ทุกตัว

ฉันเห็นหลายคนมีปัญหาบนอินเทอร์เน็ตและวิธีแก้ปัญหาของพวกเขาคือติดตั้งโดยใช้ barrier = 0 นั่นจะปิดการใช้งาน Journaling ทั้งหมดหรือไม่ เซิร์ฟเวอร์ของฉันมี UPS และอยากทำเช่นนั้นฉันควรทำอย่างไร

วางฐานข้อมูลบนระบบไฟล์ที่ไม่ทำเจอร์นัล อย่างน้อยเซิร์ฟเวอร์ที่ใหญ่กว่า (oracle, sql server) มีฟังก์ชั่นเจอร์นัลของตัวเอง (บันทึกธุรกรรม) และปรับแต่ง IO ให้เหมาะสม คุณมีบันทึกและฐานข้อมูลในระบบไฟล์และดิสก์แยกต่างหากและอาศัยการทำงานภายในฐานข้อมูลสำหรับการจัดการ IO ที่ไม่ดี โดยปกติจะไม่มีการเปลี่ยนแปลงระบบไฟล์ (การตั้งค่าที่ใหญ่กว่า) ยกเว้นวันที่เขียนเพราะไฟล์ไม่ขยาย - พวกเขาจะถูกสร้างขึ้นด้วยขนาด "สุดท้าย" (ตกลงผู้ดูแลระบบสามารถเปลี่ยนได้) และการเปลี่ยนแปลงเป็นไปตามที่ฉันบอกว่าติดตามโดยฐานข้อมูล บันทึกธุรกรรมระดับ

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

จะมีการแลกเปลี่ยนระหว่างความยืดหยุ่นและประสิทธิภาพเสมอ

ด้วย MySQL บน ext4 อุปสรรค = 1 ค่าเริ่มต้นย่อมทำให้การทำงานช้าลง แต่การกระทำแรกไม่ควรที่จะปิดการใช้งานการทำเจอร์นัลหรือเปิด data = writeback

ก่อนอื่นหากความยืดหยุ่นมีความสำคัญสูง RAID ที่มีแบตเตอรี่สำรองจะคุ้มค่าอย่างแน่นอน

ตัวเลือกการเมานต์ที่ฉันเลือกโดยเฉพาะอย่างยิ่งใน RAID ที่ไม่ใช่แบตเตอรี่สำรองคือ:

/dev/mapper/vg-mysql--data  /var/lib/mysql/data ext4  defaults,noatime,nodiratime,barrier=1,data=ordered  0 0

นี่เป็นการจงใจไม่ได้ใช้ data = writeback เพราะฉันไม่ต้องการเสี่ยงต่อความเสียหายของระบบไฟล์ที่เกิดขึ้นใน "ข้อมูลเก่าที่จะปรากฏในไฟล์หลังจากเกิดความผิดพลาดและการกู้คืนเจอร์นัล" (อ้างจากman mount)

การกำหนดค่าในอุดมคติใน my.cnf สำหรับความยืดหยุ่นเต็มรูปแบบรอบการตั้งค่าที่เกี่ยวข้อง I / O คือ:

[mysqld]
sync_binlog = 1
innodb_flush_log_at_trx_commit = 1

ฉันได้เลือกลำดับของการแลกเปลี่ยนต่อไปนี้เพื่อเพิ่มประสิทธิภาพ:

1. sync_binlog = 0: นี่เป็นการกำหนดค่า MySQL ตัวแรกที่ฉันเปลี่ยนไปจากความยืดหยุ่นเต็มที่ เหตุผลของเรื่องนี้คือมันให้การปรับปรุงประสิทธิภาพอย่างมีนัยสำคัญโดยเฉพาะอย่างยิ่งที่binlog_format=row(น่าเสียดายที่จำเป็นสำหรับจิรา) ฉันใช้แบบจำลอง MySQL เพียงพอในคลัสเตอร์ที่ถ้า binlog จะเสียหายจากสถานการณ์การสูญเสียพลังงานฉันจะทำสำเนาไบนารีจากแบบจำลองอื่น
2. innodb_flush_log_at_trx_commit = 2: ในขณะที่จำเป็นต้องใช้ค่า 1 สำหรับการปฏิบัติตามข้อกำหนดของ ACID อย่างเต็มรูปแบบด้วยค่า 2 "บัฟเฟอร์การบันทึกจะถูกเขียนไปยังไฟล์ในแต่ละการกระทำ แต่การดำเนินการ flush to disk ไม่ได้ดำเนินการอย่างไรก็ตามการลบบน ไฟล์บันทึกจะเกิดขึ้นหนึ่งครั้งต่อวินาทีเช่นกันเมื่อค่าเป็น 2 โปรดทราบว่าการล้างข้อมูลครั้งละหนึ่งวินาทีไม่ได้รับประกัน 100% ว่าจะเกิดขึ้นทุกวินาทีเนื่องจากปัญหาการกำหนดเวลาในกระบวนการ " (อ้างจาก MySQL เอกสาร)
3. data=writebackการปรับปรุงการติดตั้งตัวเลือกในการใช้งาน โปรดทราบว่าหากนี่เป็นระบบไฟล์รูทของคุณคุณจะต้องผ่านตัวเลือกบรรทัดคำสั่งเคอร์เนล ฉันใส่กันไม่กี่ขั้นตอนในที่ที่coderwall
4. innodb_flush_methodทดสอบค่าต่างๆของ O_DIRECT จะแสดงเพื่อปรับปรุงประสิทธิภาพการทำงานในเวิร์กโหลดบางตัว แต่ไม่ได้ระบุว่าสิ่งนี้จะทำงานในสภาพแวดล้อมของคุณ
5. อัพเกรดเป็น SSDs ซึ่งในกรณีที่คุณยังจะต้องการที่จะเพิ่มinnodb_io_capacityและปรับแต่งการตั้งค่าเช่นinnodb_adaptive_flushing, innodb_read_io_threads, innodb_write_io_threads, innodb_purge_threadsและการตั้งค่าที่เป็นไปได้อื่น ๆ

อาจเป็นไปได้ว่าแบ็กเอนด์ I / O ของคุณไม่สามารถรับมือกับโหลดทั้งหมดได้ดี คุณควรตรวจสอบให้แน่ใจว่าระบบไฟล์ของคุณไม่ได้ทำการบันทึกข้อมูล ฉันขอแนะนำให้ใช้data=writeback,relatime,nobarrierพารามิเตอร์เพื่อเมาท์สำหรับพาร์ติชันข้อมูลของฐานข้อมูลของคุณเป็นการเพิ่มประสิทธิภาพอย่างรวดเร็วและสกปรกครั้งแรก

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

นี่เป็นคำถามเก่า แต่เราต้องเผชิญกับปัญหาเดียวกัน (High IO รอและความเร็วในการแทรก / อัปเดตแย่มาก) ในสัปดาห์ที่ผ่านมาบนเซิร์ฟเวอร์เฉพาะใหม่และวิธีนี้แก้ปัญหานี้ได้โดยตรง

การปิดใช้งานการtune2fs -O "^has_journal" /dev/<drive>ทำเจอร์นัลด้วยเป็นวิธีแก้ปัญหาที่เร็วที่สุดเนื่องจากไม่ต้องรอการรอ IO เนื่องจากกระบวนการ JDB2 แต่สิ่งนี้ไม่แนะนำหากคุณไม่มีไดรฟ์แบตเตอรี่สำรองเพราะคุณจะสูญเสียข้อมูลในกรณีที่เกิดข้อขัดข้อง ตาราง InnoDB ปลอดภัยหากคุณdoublewriteเปิดใช้งานใน MySQL แต่ไฟล์เช่น. frm บันทึก ฯลฯ ไม่ปลอดภัย เราพยายามย้ายไฟล์เหล่านี้ไปยังไดรฟ์อื่น (โดยเฉพาะอย่างยิ่งบันทึกถังขยะ) แต่ jdb2 IO ยังคงรออยู่ ดังนั้นมันจึงไม่ทำให้เราสบายใจ

data=writeback,relatime,nobarrierไม่ได้ช่วยเร่งความเร็วในการเขียน / อ่านมากเท่ากับการปิดใช้งานการบันทึกในพาร์ติชันทั้งหมด ตัวเลือกเพิ่มเติมสำหรับ ext4 อยู่ในdoc Ext4

sync_binlogกระทำผิดจริงในกรณีของเราก็คือ เราได้ตั้งค่าไว้1ใน/etc/mysql/my.cnfและมันก็ฆ่าการแสดง

Percona ตรวจสอบได้ที่นี่ เราตั้งค่าให้มันเป็นค่าเริ่มต้นของ0และประสิทธิภาพการทำงานที่มากกว่า 500%

คุณใช้โปรแกรมฐานข้อมูลใดในการแทรกข้อมูลนี้

ถ้าเป็น MyISAM: ที่ต้องล็อกทั้งตารางในระหว่างการเขียนดังนั้นการรันเธรดการแทรกแบบพร้อมกันจะทำให้ระบบใด ๆ ไม่ว่าจะมีประสิทธิภาพเพียงใด

ตรวจสอบให้แน่ใจว่าคุณกำลังใช้ InnoDB สำหรับตารางเหล่านี้

นอกจากนี้ไม่เกี่ยวข้องโดยตรงกับ mysql แต่ HD บางตัวมีปัญหากับ ext4 เนื่องจากการจัดการพลังงานที่ก้าวร้าว ... เมื่อเกิดเหตุการณ์ดังกล่าวโหลดของเครื่องจะเพิ่มขึ้นโดยไม่มีกิจกรรมใด ๆ ที่ชัดเจน

ลองปิดการใช้งาน ก่อนอื่นให้ตรวจสอบค่าที่คุณมี (ถ้าคุณต้องการนำกลับมาโดยไม่ต้องบูตเครื่องใหม่) จากนั้นปิดใช้งาน

ตรวจสอบค่าปัจจุบัน:

    hdparm -B /dev/sda

ปิดการใช้งาน

   hdparm -B 255 /dev/sda

(หรืออะไรก็ตามที่เป็น HD ของคุณ) และทดสอบ อาจจะไม่ช่วยแก้ไขปัญหาส่วนใหญ่ แต่อาจช่วยให้ผู้ใช้บางคนออกมี การรีบูตเครื่องจะรีเซ็ตค่าหรือแทนที่ 255 สำหรับค่าก่อนหน้าด้วยตนเอง

หากช่วยได้ให้ตรวจสอบ/etc/default/hdparmหรือ/etc/hdparm.confกำหนดค่าถาวรมากขึ้นโดยการตั้งค่าในการบูต