ระบบไฟล์ที่ดีที่สุดสำหรับการแทรกประสิทธิภาพบน PostgreSQL คืออะไร?

ฉันอยากรู้ว่ามีใครทำการทดลองหรือเปรียบเทียบระหว่างระบบไฟล์กับประสิทธิภาพของฐานข้อมูลหรือไม่ บน Linux ฉันสงสัยว่าระบบไฟล์ที่ดีที่สุดสำหรับฐานข้อมูล postgres คืออะไร นอกจากนี้การตั้งค่าใด (inode และอื่น ๆ ) เหมาะสำหรับมัน? นี่เป็นสิ่งที่อาจแตกต่างกันอย่างมากตามข้อมูลในฐานข้อมูลหรือไม่

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

อย่างไรก็ตามฉันต้องการรับคำแนะนำเกี่ยวกับประสิทธิภาพการแทรกที่ต่างจากการอ่านมากที่สุด ขอบคุณสำหรับคำตอบที่ยอดเยี่ยม!

ซื้อสำเนา "ประสิทธิภาพสูง postgresql" โดย Greg Smith มันเป็นหนังสือที่ยอดเยี่ยมและสองบทขึ้นไปเกี่ยวกับ Disk Hardware และระบบไฟล์ คุณจะได้เรียนรู้มากมาย

กล่าวโดยย่อ: ไม่มีคำตอบสั้น ๆ

แต่ฉันจะพยายามทำให้หน้าร้อน:

• อย่าใช้ ext2 จนกว่าคุณจะรู้ว่าคุณกำลังทำอะไรอยู่
• ด้วย ext3 ระวังจุดตรวจสอบ spikes เนื่องจากการโทร fsync ดูหน้า 113 และ 82 และ 79
• ใช้ ext4 หรือ xfs
• มีตัวเลือกอื่น ๆ

แต่เมื่อคุณถามตัวเองว่าควรใช้ FS อะไรคุณควรอ่านหนังสือเล่มนี้!

ก่อนอื่นคุณต้องการระบบไฟล์ที่เชื่อถือได้ก่อนและอย่างรวดเร็วหนึ่งวินาที กฎตัวเลือกบางอย่างออกมา ...

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

ในทางทฤษฎีแล้วคุณไม่จำเป็นต้องใช้ระบบไฟล์ที่ทำเจอร์นัลสำหรับไดเรกทอรี pg_xlog แต่ความแตกต่างของความเร็วนั้นเล็กมาก แต่ก็ไม่คุ้มกับมัน สำหรับไดเร็กทอรีข้อมูลคุณควรมีระบบไฟล์ที่ทำเจอร์นัลเมทาดาทาอยู่เสมอ

ระบบการจัดการฐานข้อมูลใช้การทำเจอร์นัลของตนเองผ่านบันทึกฐานข้อมูลดังนั้นการติดตั้ง DBMS เช่นนี้บนระบบไฟล์ที่ถูกเจอร์นัลจะลดประสิทธิภาพลงผ่านกลไกสองกลไก:

1. การทำเจอร์นัลซ้ำซ้อนเพิ่มปริมาณของกิจกรรมดิสก์

2. โครงร่างฟิสิคัลดิสก์สามารถแยกส่วนได้ (แม้ว่าระบบไฟล์ journalling บางระบบจะมีกลไกในการล้างข้อมูลนี้)

3. กิจกรรมดิสก์จำนวนมากสามารถเติมบันทึกประจำวันทำให้เงื่อนไข 'ดิสก์เต็ม' ปลอม

ฉันได้เห็นอินสแตนซ์เมื่อหลายปีก่อนที่สิ่งนี้ทำบนระบบไฟล์ LFS ในการติดตั้ง Baan บนกล่อง HP / UX ระบบมีประสิทธิภาพการทำงานถาวรและปัญหาความเสียหายของข้อมูลที่ไม่สามารถวินิจฉัยได้จนกระทั่งมีคนทำงานว่าระบบไฟล์ถูกฟอร์แมตด้วย LFS

วอลุ่มที่เก็บไฟล์ฐานข้อมูลจะมีไฟล์ขนาดใหญ่จำนวนเล็กน้อย เซิร์ฟเวอร์ DBMS โดยปกติจะมีการตั้งค่าที่กำหนดจำนวนบล็อกที่อ่านใน I / O เดียว ตัวเลขที่น้อยลงจะเหมาะสมสำหรับระบบประมวลผลธุรกรรมปริมาณมากเนื่องจากจะลดการแคชข้อมูลซ้ำซ้อน ตัวเลขที่มีขนาดใหญ่ขึ้นจะเหมาะสมสำหรับระบบเช่นคลังข้อมูลที่อ่าน sequetial จำนวนมาก หากเป็นไปได้ให้ปรับขนาดบล็อกการจัดสรรระบบไฟล์ของคุณให้เป็นขนาดเดียวกับการอ่านแบบหลายบล็อกที่ตั้งค่า DBMS เป็น

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

โวลุ่ม RAID-5 มีค่าใช้จ่ายในการเขียนมากกว่าโวลุ่ม RAID-10 ดังนั้นฐานข้อมูลไม่ว่างที่มีทราฟฟิกการเขียนจำนวนมากจะทำงานได้ดีขึ้น (มักจะดีกว่า) ใน RAID-10 บันทึกควรนำดิสก์ไดรฟ์ที่แยกออกจากกันไปยังข้อมูล หากฐานข้อมูลของคุณมีขนาดใหญ่และส่วนใหญ่อ่านอย่างเดียว (เช่นคลังข้อมูล) อาจมีกรณีที่จะวางไว้ในโวลุ่ม RAID-5 หากนี่ไม่ได้ทำให้กระบวนการโหลดช้าลงจนเกินไป

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

ฉันทำรายงานแบบละเอียด แต่มันเป็นภาษาฝรั่งเศสเท่านั้น หากคุณอ่านภาษาฝรั่งเศสหรือมีความสุขกับเครื่องมือแปลอัตโนมัติ ... คุณสามารถนำวิธีการนั้นมาใช้ใหม่และดำเนินการด้วยตนเอง

บทสรุปผู้บริหาร: ฉันใช้ pgbench ตัวกำหนดตารางเวลา Linux I / O มีความสำคัญน้อยมากสำหรับการแสดงและระบบไฟล์มีเพียงเล็กน้อยเท่านั้น ดังนั้นหากคุณกำลังรีบให้เลือกค่าเริ่มต้น ฉันเลือก JFS

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

ฉันทำการทดสอบไม่กี่เดือนที่ผ่านมา:

ฉันมีโปรแกรมทดสอบขนาดเล็กที่สร้าง 50 เธรดโดยที่ทุกเธรดแทรก 1,000 แถว (หรือถ้า 10,000) ลงในตารางเดียวกัน

• ด้วยฐานข้อมูลบน EXT3 และดิสก์ RAID5 4 ตัวใช้เวลา 50 วินาที
• ด้วยตารางบน ramdisk (ใช้ tablespace) มันยังคงใช้เวลา 50 วินาที เหตุผลที่ไม่เร็วขึ้นคือทุกอย่างถูกบันทึกไว้ในไดเรกทอรี pg_xlog ซึ่งยังคงอยู่ใน RAID 5 เดียวกัน
• ฉันย้าย pg_xlog ไปยังดิสก์ 4 RAID0 (แถบ) และโปรแกรมเดียวกันทำงานใน 40 วินาที
• เพื่อจุดประสงค์ในการทดสอบฉันย้าย pg_xlog ไปยัง ramdisk และมีทุกอย่างใน EXT3 4 ดิสก์ RAID โปรแกรมเสร็จสิ้นภายในเวลาไม่ถึง 5 วินาที

แต่การมี pg___xlog ในซอฟต์แวร์ ramdisk ไม่ใช่ตัวเลือก: หากคุณสูญเสียเนื้อหาของไดเรกทอรี pg_xlog postgres จะไม่เริ่มทำงาน (แต่มี ramdisks ฮาร์ดแวร์พร้อมแบตเตอรี่สำรองที่อาจเป็นที่สนใจ)

IMHO: ใช้ filesytem ที่คุณคุ้นเคยกับไฟล์ฐานข้อมูลมากที่สุด ย้าย pg_xlog (ด้วย symlink ดูเอกสารประกอบ) ไปยังอุปกรณ์ที่เร็วที่สุดที่คุณมี

ฉันเคยเห็นแล้วว่าได้จดจำว่า FreeBSD ที่ปรับแต่งแล้วจะให้ประสิทธิภาพการทำงานที่เพิ่มขึ้นเล็กน้อยเมื่อเทียบกับระบบปฏิบัติการอื่น แม้ว่าฉันจะแน่ใจว่าข้อมูลนี้ล้าสมัยและอาจเป็นตำนานในตอนแรก แต่คุณสามารถลองใช้ได้ดูแนวทางนี้สำหรับการตั้งค่าเคอร์เนล: http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html