ระบบไฟล์ไฟล์จำนวนมากในไดเรกทอรีเดียว

ตกลงไม่ใหญ่มาก แต่ฉันต้องใช้สิ่งที่มีประมาณ 60,000 ไฟล์ที่มีขนาดเฉลี่ย 30kb ถูกเก็บไว้ในไดเรกทอรีเดียว

ไฟล์จะถูกเข้าถึงแบบสุ่ม แต่เมื่อสร้างขึ้นจะไม่มีการเขียนไปยังระบบไฟล์เดียวกัน ปัจจุบันฉันใช้ Ext3 แต่พบว่าช้ามาก ข้อเสนอแนะใด ๆ

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

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

หนึ่งพันล้านไฟล์บน Linux

ผู้เขียนบทความนี้ขุดลงในปัญหาประสิทธิภาพการทำงานบางอย่างบนระบบไฟล์ที่มีไฟล์จำนวนมากและทำการเปรียบเทียบประสิทธิภาพของระบบไฟล์ต่างๆ ext3, ext4 และ XFS สิ่งนี้ทำให้เป็นแบบสไลด์โชว์ http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

ไฟล์จำนวนมากในไดเรกทอรีบน ext3 ถูกกล่าวถึงในความยาวที่เว็บไซต์น้องสาวstackoverflow.com

ในความคิดของฉัน 60,000 ไฟล์ในหนึ่งไดเรกทอรีบน ext3 นั้นยังห่างไกลจากอุดมคติ แต่ขึ้นอยู่กับข้อกำหนดอื่น ๆ ของคุณมันอาจจะดีพอ

ตกลง. ฉันทำการทดสอบเบื้องต้นโดยใช้ ReiserFS, XFS, JFS, Ext3 (เปิดใช้งาน dir_hash) และ Ext4dev (2.6.26 เคอร์เนล) ความประทับใจครั้งแรกของฉันคือทั้งหมดนั้นเร็วพอ (บนเวิร์คสเตชั่นเนื้อของฉัน) - ปรากฎว่าเครื่องจักรที่ใช้ในการผลิตจากระยะไกลมีโปรเซสเซอร์ที่ค่อนข้างช้า

ฉันมีประสบการณ์แปลก ๆ กับ ReiserFS แม้ในการทดสอบครั้งแรก ดูเหมือนว่า JFS มีความต้องการซีพียูน้อยลง 33% เมื่อเทียบกับคุณสมบัติอื่น ๆ ทั้งหมดและจะทำการทดสอบบนเซิร์ฟเวอร์ระยะไกล ถ้ามันทำงานได้ดีพอฉันจะใช้มัน

ฉันกำลังเขียนแอพพลิเคชั่นที่เก็บไฟล์จำนวนมากและจำนวนมากถึงแม้ว่าของฉันจะใหญ่กว่าและฉันมี 10 ล้านในนั้นที่ฉันจะแยกไปหลายไดเรกทอรี

ext3 ช้าเนื่องจากการใช้งาน "รายการเชื่อมโยง" ที่เป็นค่าเริ่มต้น ดังนั้นหากคุณมีไฟล์จำนวนมากในไดเรกทอรีเดียวนั่นหมายถึงการเปิดหรือสร้างไฟล์อื่นจะช้าลงเรื่อย ๆ มีบางสิ่งที่เรียกว่าดัชนี htree ที่พร้อมใช้งานสำหรับ ext3 ที่รายงานว่าปรับปรุงสิ่งต่าง ๆ ได้อย่างมาก แต่จะใช้ได้กับการสร้างระบบไฟล์เท่านั้น ดูที่นี่: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

เนื่องจากคุณจะต้องสร้างระบบไฟล์ใหม่และเนื่องจากข้อ จำกัด ext3 คำแนะนำของฉันคือให้คุณดูการใช้ ext4 (หรือ XFS) ฉันคิดว่า ext4 นั้นเร็วกว่าเล็กน้อยด้วยไฟล์ที่เล็กลงและสร้างใหม่ได้เร็วขึ้น ดัชนี Htree เป็นค่าเริ่มต้นใน ext4 เท่าที่ฉันรู้ ฉันไม่เคยมีประสบการณ์กับ JFS หรือ Reiser จริงๆ แต่ฉันเคยได้ยินคนแนะนำมาก่อน

ในความเป็นจริงฉันอาจทดสอบระบบไฟล์หลาย ๆ ระบบ ทำไมไม่ลอง ext4, xfs & jfs และดูว่าอันไหนให้ประสิทธิภาพโดยรวมที่ดีที่สุด?

สิ่งที่นักพัฒนาซอฟต์แวร์บอกฉันว่าสิ่งที่สามารถเพิ่มความเร็วในโค้ดแอปพลิเคชันไม่ได้เป็นการโทร "stat + open" แต่จะเป็น "open + fstat" ครั้งแรกช้ากว่าครั้งที่สองอย่างมาก ไม่แน่ใจว่าคุณมีการควบคุมหรือมีอิทธิพลเหนือสิ่งนั้นหรือไม่

ดูโพสต์ของฉันที่นี่ใน stackoverflow การจัดเก็บและเข้าถึงไฟล์ได้มากถึง 10 ล้านไฟล์ใน Linux มีคำตอบและลิงก์ที่มีประโยชน์มาก

การใช้ tune2fs เพื่อเปิดใช้ dir_index อาจช่วยได้ วิธีดูว่าเปิดใช้งานหรือไม่:

sudo tune2fs -l /dev/sda1 | grep dir_index

หากไม่ได้เปิดใช้งาน:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

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

ext3 และต่ำกว่ารองรับไฟล์ได้สูงสุด 32768 ไฟล์ต่อไดเรกทอรี ext4 รองรับได้ถึง 65536 ในจำนวนจริงของไฟล์ แต่จะช่วยให้คุณมีมากขึ้น (มันจะไม่เก็บไว้ในไดเรกทอรีซึ่งไม่สำคัญสำหรับวัตถุประสงค์ของผู้ใช้ส่วนใหญ่)

นอกจากนี้วิธีการจัดเก็บไดเรกทอรีในระบบไฟล์ ext * นั้นเป็นรายการใหญ่หนึ่งรายการ ในระบบไฟล์ที่ทันสมัยกว่า (Reiser, XFS, JFS) พวกเขาจะถูกจัดเก็บเป็น B-trees ซึ่งมีประสิทธิภาพมากขึ้นสำหรับชุดขนาดใหญ่

คุณสามารถจัดเก็บ inode ของไฟล์แทนชื่อไฟล์: การเข้าถึงหมายเลข inode ควรเร็วกว่านั้นมากในการแก้ไขชื่อไฟล์

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

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

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