ฉันพยายามมองหาเกณฑ์มาตรฐานในการแสดงระบบไฟล์ต่างๆด้วย MySQL InnoDB แต่หาไม่เจอ
ปริมาณงานฐานข้อมูลของฉันคือ OLTP บนเว็บทั่วไปอ่านประมาณ 90% เขียน 10% IO แบบสุ่ม
ระบบไฟล์ที่ได้รับความนิยมเช่น ext3, ext4, xfs, jfs, Reiserfs, Reiser4 และอื่น ๆ ที่คุณคิดว่าดีที่สุดสำหรับ MySQL?
คำตอบ:
คุณให้ความสำคัญกับข้อมูลมากน้อยเพียงใด
อย่างจริงจังแต่ละระบบไฟล์มีการแลกเปลี่ยนของตัวเอง ก่อนที่ฉันจะไปไกลกว่านี้ฉันเป็นแฟนตัวยงของ XFS และ Reiser ทั้งคู่แม้ว่าฉันจะใช้ Ext3 บ่อยครั้งก็ตาม ดังนั้นที่นี่ไม่มีอคติระบบไฟล์จริงในที่ทำงานเพียงแจ้งให้คุณทราบ ...
หากระบบไฟล์นั้นเล็กกว่าคอนเทนเนอร์สำหรับคุณให้ไปกับสิ่งที่ให้เวลาการเข้าถึงที่ดีที่สุดกับคุณ
หากข้อมูลมีค่าที่สำคัญคุณจะต้องหลีกเลี่ยง XFS ทำไม? เพราะถ้ามันไม่สามารถกู้คืนส่วนของไฟล์ที่ถูกทำเจอร์นัลมันจะทำให้บล็อกเป็นศูนย์และทำให้ข้อมูลไม่สามารถกู้คืนได้ ปัญหานี้จะได้รับการแก้ไขใน Linux Kernel 2.6.22
ReiserFS เป็นระบบไฟล์ที่ดีโดยมีเงื่อนไขว่ามันไม่เคยเกิดปัญหาอย่างหนัก การกู้คืนเจอร์นัลทำงานได้ดี แต่ถ้าด้วยเหตุผลบางอย่างที่ทำให้ข้อมูลพาร์ริชันของคุณหลวมหรือบล็อกหลักของระบบไฟล์ถูกพัดหายไปคุณอาจมีปัญหาถ้ามีพาร์ติชั่น ReiserFS หลายตัวบนดิสก์ - เพราะกลไกการกู้คืนสแกน ดิสก์ทั้งภาคโดยภาคที่กำลังมองหาสิ่งที่มัน "คิด" คือจุดเริ่มต้นของระบบแฟ้ม หากคุณมีพาร์ติชั่นสามตัวที่มี ReiserFS แต่มีเพียงพาร์ติชั่นเดียวคุณสามารถจินตนาการถึงความโกลาหลที่จะเกิดขึ้นเมื่อกระบวนการกู้คืนรวมเข้ากับระเบียบ Frankenstein จากอีกสองระบบ ...
Ext3 คือ "ช้า" ใน "ฉันมีไฟล์ 32,000 ไฟล์และต้องใช้เวลาในการหาไฟล์ทั้งหมดที่ทำงานls" หากคุณจะมีตารางชั่วคราวขนาดเล็กหลายพันแห่งทุกที่คุณจะรู้สึกเศร้าเล็กน้อย ขณะนี้เวอร์ชันที่ใหม่กว่ามีตัวเลือกดัชนีที่ลดทอนการสำรวจไดเรกทอรีอย่างมาก แต่ก็ยังสามารถเจ็บปวดได้
ฉันไม่เคยใช้ JFS ฉันสามารถแสดงความคิดเห็นได้ว่าการตรวจสอบทุกครั้งที่ฉันอ่านมานั้นเป็นอะไรที่ "แข็ง แต่ไม่ใช่เด็กที่เร็วที่สุดในบล็อก" อาจได้รับการสอบสวน
พอมีข้อเสียลองดูข้อดี:
XFS:
ReiserFS:
ext3:
ดังนั้นคุณจะเห็นว่าแต่ละคนมีนิสัยใจคอของตัวเอง คำถามคืออะไรที่แปลกประหลาดที่สุดสำหรับคุณ?
นอกจากนี้ยังอาจคุ้มค่าที่จะทราบว่าคุณสามารถเรียกใช้ InnoDB ได้โดยไม่ต้องใช้ระบบไฟล์และปรับปรุงประสิทธิภาพโดยไม่ต้องมีค่าใช้จ่ายระบบไฟล์ ฉันไม่แน่ใจว่าฉันจะแนะนำ แต่ฉันเคยใช้มาก่อนโดยไม่มีปัญหา
นอกจากนี้หากคุณใช้การอ่าน 90% และการเขียน 10% เว้นแต่ว่าคุณต้องการความสามารถในการทำธุรกรรมของ InnoDB คุณอาจดูการย้ายไปที่ MyISAM เพื่อประสิทธิภาพการอ่านที่ดีขึ้น
คำตอบที่นี่มีการคัดค้านอย่างจริงจังและจำเป็นต้องอัปเดตเนื่องจากจะเกิดขึ้นในผลลัพธ์ของ Google
สำหรับสภาวะแวดล้อม produciton, XFS ทุกเวลา. XFS ถูกเจอร์นัลและไม่บล็อก ตรวจสอบให้แน่ใจว่าคุณมีตัวแปรต่อไปนี้สำหรับฐานข้อมูล MySQL ที่ทันสมัย (2011/2012) โดยใช้ InnoDB ในการผลิต:
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 1 # an ACID requirement
sync_binlog = 1 # more ACID
innodb_flush_method = O_DIRECT
อย่าใช้ EXT3 หรือแม้แต่ EXT4 BTRFS หนึ่งวันจะไปถึงที่นั่น
EXT3 และอาจ EXT4 ล็อคที่ระดับไอโหนดไม่ใช่อัจฉริยะ!
แหล่งที่มา: - www.mysqlperformanceblog.com - http://dev.mysql.com/doc/internals/en/index.html - ทำความเข้าใจกับ MySQL Internals โดย Sasha Pachev - https://www.facebook.com/note.php? note_id = 10150210901610933 - http://oss.sgi.com/projects/xfs/training/ - ชุดแกว่งตัวทดลองและข้อผิดพลาดบางอย่าง
แก้ไข: การปรับปรุง EXT4 น่าจะทำได้ดีในกลางปี 2013! BTRFS ยังคงเป็นตัวเลือกที่ดี และ RHEL อาจทำให้ XFS เป็นระบบไฟล์เริ่มต้นใหม่ อย่าใช้ EXT3 อีกครั้ง
รุ่นสั้นคือคำแนะนำที่ใกล้เคียงที่สุดที่ฉันเคยเห็น MySQL ทำในระบบไฟล์คือ XFS แต่ ext3 ควรจะโอเคเช่นกัน ext4 สัญญาว่าจะปรับปรุงให้ดีขึ้น แต่ก็ยังไม่เสถียรเท่าที่ควร ท้ายปี.
หากคุณใช้ระบบไฟล์คลัสเตอร์ CXFS, OCFS2 และ GFS ทั้งหมดควรจะโอเค
ฉันขอเตือนอย่างยิ่งยวดต่อสัญญาซื้อขายล่วงหน้าของ Reiser และ JFS แม้ว่าครั้งหนึ่งที่ดีจะพ่ายแพ้โดย XFS และ ext4 ซึ่งส่วนใหญ่มีการปรับใช้กันอย่างแพร่หลาย
มันไม่น่าจะสร้างความแตกต่างได้มากนัก ไปกับทุกสิ่งที่การกระจายของคุณใช้เป็นค่าเริ่มต้นหากเพียงพอ
ใช้ความพยายามของคุณในการปรับแต่งสิ่งต่าง ๆ - รับ ram มากพอ - รับตัวควบคุมการจู่โจมที่ไม่ดูด - และแก้ไขการใช้ฐานข้อมูลของแอปพลิเคชัน (ab) ของแอปพลิเคชัน (NB): นี่คือผู้ร้ายหลักในกรณีส่วนใหญ่ เสร็จสิ้น)
พิจารณาอย่างรอบคอบระบบไฟล์ที่คุณใส่ mysql ของคุณ tmpdir; สิ่งนี้จะส่งผลกระทบต่อประสิทธิภาพโดยเฉพาะข้อความค้นหาที่ทำจากไฟล์บนดิสก์ () s (ดูอธิบายสำหรับรายละเอียดเพิ่มเติม)
ฉันคิดว่าระบบไฟล์ที่รองรับการจัดสรรล่าช้านั้นมีประโยชน์จริง ๆ เพราะคุณสามารถหลีกเลี่ยง IO ได้อย่างสมบูรณ์สำหรับไฟล์อายุสั้นเมื่อมี RAM เพียงพอที่จะเก็บไว้ในแคช ตัวอย่างเช่น XFS ไม่ต้องกังวลกับการเขียนไฟล์เลยซึ่งจะถูกลบและปิดก่อนที่จะถูกจัดสรร
แน่นอนว่าการใส่ tmpdir บน tmpfs นั้นมีความน่าสนใจจากมุมมองด้านประสิทธิภาพ แต่นำไปสู่ความเสี่ยงที่จะหมดพื้นที่และมีข้อความค้นหาที่จะประสบความสำเร็จ
ฉันไม่พบบทความล่าสุดที่มีเกณฑ์มาตรฐาน "roundups" บน MySQL ที่ทำงานบนระบบไฟล์ต่าง ๆ ด้วยภาระงานที่คุณอธิบายฉันสงสัยว่าการแตกแฟรกเมนต์ระดับไฟล์จะเป็นปัญหามาก หากไม่มีเกณฑ์มาตรฐานอย่างเป็นทางการฉันไม่สามารถพูดอะไรก็ได้ที่คุณควรใช้อย่างเป็นทางการ แต่ไส้ของฉันบอกว่าทุกระบบไฟล์ที่คุณกล่าวถึงข้างต้นจะทำงานอย่างคร่าว ๆ ใน ballpark เดียวกัน (เช่นทั้งหมดในลำดับเดียวกันสำหรับขนาดประสิทธิภาพ) .
ฐานข้อมูลกำลังแสดงอยู่เนื่องจากระบบไฟล์กำลังจัดการขอบเขตขนาดใหญ่ที่เอ็นจิ้นการจัดเก็บกำลังเข้าถึงอยู่
ถึงกระนั้นมันก็น่าสนใจที่จะทำการปัดเศษประสิทธิภาพกับระบบไฟล์เหล่านั้นทั้งหมด (ฉันมีความกระตือรือร้นน้อยกว่าสำหรับ MySQL ดังนั้นฉันจะไม่ทำมันการเปรียบเทียบ Postgres, OTOH อาจจะน่าสนใจ ... )
IMHO FSs ที่มีมูลค่าสำหรับ Linux มีดังนี้:
XFS (ความเร็วในการอ่านไม่ดี) เป็นที่รู้กันดีว่าไฟของทรัพยากรระบบและรวดเร็วกับไฟล์ขนาดใหญ่ แต่ไม่ดีพอที่จะรองรับไฟล์ขนาดเล็กจำนวนมาก
ReiserFS (ความเร็วในการเขียนไม่ดี) ไม่ค่อยดีนักกับทรัพยากรระบบ แต่ทำงานได้ดีมากกับไฟล์ขนาดเล็กจำนวนมาก
EXT3 อยู่ระหว่างดำเนินการยอมรับได้ในทุกฟิลด์ (เหตุผลที่ถือว่าเป็นค่าเริ่มต้นของ linux FS)
ฉันยังไม่ได้ใช้ EXT4 ไม่ใช่ ReiserFS4 ด้วยตัวเอง แต่ฉันได้ดูมาตรฐานแล้วดูเหมือนว่า ReiserFS จะมีประสิทธิภาพดีที่สุดเมื่อพูดถึงความเร็วในการอ่านซึ่งคุณบอกว่าสำคัญที่สุดสำหรับคุณ
ดูที่นี่: ReserFS4 X Ext4 X Ext3
ฉันอยากจะแนะนำ Ext3 สำหรับความเสถียรความปลอดภัยและวุฒิภาวะ แต่ถ้าความเร็วในการอ่านเป็นสิ่งที่สำคัญที่สุดสำหรับคุณคุณควรพิจารณา ReiserFS
โปรดจำไว้ว่าคุณควรพิจารณาการใช้ CPU ความเสถียรความปลอดภัยและอื่น ๆ ก่อนเลือก FS
และแน่นอนว่าการเป็นนักบินการทดสอบและการเปรียบเทียบในสภาพแวดล้อมเฉพาะของคุณนั้นเป็นวิธีที่ดีที่สุดในการบอกว่าอะไรจะดีที่สุดสำหรับคุณ
PS: ฉันจะโพสต์มาตรฐานมากขึ้น แต่ฉันไม่สามารถโพสต์มากกว่าหนึ่งลิงก์