innodb_flush_method = O_DIRECT vs O_DSYNC ผลกระทบต่อประสิทธิภาพใน ext3 กับพาร์ติชันดิสก์ LVM


12

ในหนึ่งในสภาพแวดล้อมการผลิตของฉันเรามีสองอินสแตนซ์ที่ทำงานบนคลัสเตอร์ RedHat โดยมีหนึ่งอินสแตนซ์การผลิตที่เกี่ยวข้องกับคลัสเตอร์

เรามีหน่วยความจำหลัก 125G พร้อมพูลบัฟเฟอร์ InnoDB 24G ซึ่งครอบครองโดย instance1 & 12G ที่ครอบครองโดย instance2 ซึ่งไม่เกี่ยวข้องกับคลัสเตอร์ RedHat ทั้งข้อมูลและบันทึกธุรกรรมอยู่บนพาร์ติชั่นดิสก์ LVM พร้อมระบบไฟล์ ext3

สำหรับการเพิ่มประสิทธิภาพการทำงานที่ดีขึ้นและ I / O throughput ที่ฉันได้ตัดสินใจที่จะเปลี่ยนแปลงไปinnodb_flush_methodO_DIRECT

อ้างอิงจากเอกสารของ MySQL:

ที่ข้อมูล InnoDB และไฟล์เข้าสู่ระบบตั้งอยู่บน SAN จะได้รับพบว่าการตั้งค่าinnodb_flush_methodเพื่อO_DIRECTประสิทธิภาพสามารถลดง่ายSELECTงบโดยปัจจัยที่สาม

หมายถึงการที่มีประสิทธิภาพสูง MySQL Ver 2 และ 3 มันบอกว่านักพัฒนา InnoDB innodb_flush_method=O_DSYNCพบข้อบกพร่องเกี่ยวกับการใช้ O_SYNCและO_DSYNCคล้ายกับfsync()และfdatasync(): O_SYNCซิงค์ทั้งข้อมูลและเมตาดาต้าในขณะที่O_DSYNCซิงค์ข้อมูลเท่านั้น

ถ้านั่นดูเหมือนคำอธิบายมากมายโดยไม่มีคำแนะนำนี่คือคำแนะนำ:

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

โดย googling ฉันได้รับรายงานเปรียบเทียบนี้: O_DSYNCเทียบกับO_DIRECT

Bench Mark Report:
===================
การทดสอบการทำธุรกรรมที่ซับซ้อน 1B Row, 64 เธรด

 * SAN O_DIRECT: คำขออ่าน / เขียน: 31560140 (8766.61 ต่อวินาที)
 * SAN O_DSYNC: คำขออ่าน / เขียน: 5179457 (1438.52 ต่อวินาที)
 * SAN fdatasync: คำขออ่าน / เขียน: 9445774 (2623.66 ต่อวินาที)
 * Local-disk O_DIRECT: คำขอการอ่าน / เขียน: 3258595 (905.06 ต่อวินาที)
 * Local-disk O_DSYNC: คำขออ่าน / เขียน: 3494632 (970.65 ต่อวินาที)
 * Local-disk fdatasync: คำขออ่าน / เขียน: 4223757 (1173.04 ต่อวินาที

อย่างไรก็ตามO_DIRECTปิดการใช้งานแคชระดับระบบปฏิบัติการที่สามารถทำการแคชซ้ำซึ่งแสดงปริมาณงาน I / O ที่ดีขึ้น

เป็นการดีที่จะไปกับO_DIRECTมากกว่าO_DSYNC? ตัวเลือกทั้งสองนี้ค่อนข้างสับสน ตัวเลือกใดสามารถแสดงปริมาณงาน I / O ที่ดีขึ้นและการปรับปรุงประสิทธิภาพโดยไม่ส่งผลกระทบต่อข้อมูลอ่าน / เขียนโดยเฉพาะในการผลิต มีคำแนะนำที่ดีกว่าจากประสบการณ์ส่วนตัวของคุณหรือไม่?

ฉันเห็น Rolando Update ในโพสต์ :

ยังคงมีความสับสนเล็กน้อยในพารามิเตอร์ทั้งสองนี้ ที่ฉันจะได้เห็นส่วนใหญ่ของแม่แบบการผลิตการกำหนดค่าใช้O_DIRECTฉันไม่ได้เห็นใด ๆ O_DSYNCที่แนะนำ

ระบบ

  • MySQL 5.1.51-enterprise-gpl-pro-log
  • Red Hat Enterprise Linux Server รีลีส 5.5
  • DELL DRAC พร้อม Raid Controller ที่มีแคชการเขียนกลับแบตเตอรี่ 512MB
  • คอนโทรลเลอร์ Dell PERC H700 พร้อมแบตเตอรี่สำรอง (BBU)

ข้อมูลเพิ่มเติม

mysql> แสดงตัวแปรเช่น 'innodb_thread_concurrency'; 

+ --------------------------- + ------- +
| Variable_name | ค่า |
+ --------------------------- + ------- + 
| innodb_thread_concurrency | 96 |
+ --------------------------- + ------- + 
1 แถวในชุด (0.00 วินาที) 

mysql> แสดงตัวแปรเช่น 'innodb_read_io_threads'; 
ชุดว่าง (0.00 วินาที) 

mysql> แสดงตัวแปรเช่น 'innodb_write_io_threads'; 
ชุดว่าง (0.00 วินาที)

เราใช้ปลั๊กอินเริ่มต้นดังนั้นฉันได้โพสต์ข้อมูลจากสถานะ InnoDB:

mysql> SELECT * จากปลั๊กอิน WHERE PLUGIN_NAME ต้องการ '% innodb%' และ PLUGIN_TYPE เช่น 'STORAGE ENGINE' \ G
★★ *******
           PLUGIN_NAME: InnoDB
        PLUGIN_VERSION: 1.0
         PLUGIN_STATUS: ใช้งานอยู่
           PLUGIN_TYPE: STORAGE ENGINE
   PLUGIN_TYPE_VERSION: 50151.0
        PLUGIN_LIBRARY: NULL
PLUGIN_LIBRARY_VERSION: NULL
         PLUGIN_AUTHOR: Innobase OY
    PLUGIN_DESCRIPTION: รองรับธุรกรรมล็อคระดับแถวและปุ่มต่างประเทศ
        PLUGIN_LICENSE: GPL
1 แถวในชุด (0.00 วินาที)

คำตอบ:


7

ย้อนกลับไปเมื่อวันที่ 21 มกราคม 2009 Peter Zaitsev กล่าวถึงสิ่งต่อไปนี้บนmysqlperformanceblog.com

เป็นการเรียกร้องให้ดำเนินการ - ฉันอยากให้ใครบางคนดูว่า EXT3 สามารถแก้ไขได้ในเรื่องนี้หรือไม่เพราะเป็นระบบไฟล์ที่ใช้กันทั่วไปมากที่สุดสำหรับ Linux นอกจากนี้ยังควรตรวจสอบว่ามีสิ่งใดที่สามารถทำได้ในฝั่ง MySQL - อาจจะเปิด binlog ด้วยO_DSYNCflag หากsync_binlog=1แทนที่จะใช้ fsync จะช่วยได้ไหม หรืออาจจะมีการจัดสรรล่วงหน้า binlog จะเป็นทางออกที่ดี

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

ฉันบอกได้เลยว่าคุณไม่ได้ติดตั้งปลั๊กอินของ InnoDB ด้วยปลั๊กอิน InnoDB ควรมีตัวแปรหลายตัว

คุณควรอัปเกรด InnoDB ด้วยหนึ่งในสองวิธีต่อไปนี้:

เมื่อคุณทำเช่นนั้นคุณสามารถปรับปรุง InnoDB ให้เป็น

  • เข้าถึง CPU และ Cores เพิ่มเติม
  • เพิ่มอ่านและเขียนเธรด I / O
  • ปรับขนาดความจุของ I / O (จำเป็นอย่างยิ่งสำหรับสื่อเก็บข้อมูลที่แตกต่างกัน)

นี่คือโพสต์ที่ผ่านมาของฉันในการตั้งค่าที่คุณสามารถเปลี่ยนได้:


1

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

นอกจากนี้ยังมีคำถามสำหรับผู้เชี่ยวชาญ: ทำสายพิเศษเพื่อfsync()สำหรับO_DIRECTสาเหตุการย่อยสลายที่เห็นได้ชัดในการปฏิบัติงานโดยรวมหรือมันเป็นเล็กน้อย? ฉันยังไม่เห็นมาตรฐานแสดงให้เห็นสิ่งนี้

นอกจากนี้โปรดทราบว่า Percona ได้เปิดใช้งานความสามารถในการตั้งค่าinnodb_flush_method=ALL_O_DIRECTซึ่งมี I / O โดยตรงไม่เพียง แต่ในไฟล์ข้อมูล InnoDB แต่ยังอยู่ในบันทึกธุรกรรมของ InnoDB ในเวลาเดียวกัน


2
ย้อนกลับไปในปี 2555 บัฟเฟอร์พูลไม่ได้ปรับขนาดได้ดีสำหรับ RAM ขนาดใหญ่ดังนั้นการบัฟเฟอร์สองครั้งที่กล่าวถึงอาจดีสำหรับกรณีที่แคชระบบปฏิบัติการมีขนาดใหญ่กว่าพูลบัฟเฟอร์ Innodb มาก สำหรับ 5.6 และสูงกว่า - ฉันว่าคำตอบของคุณถูกต้องสมบูรณ์
noonex
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.