จำนวนไดเรกทอรีย่อยส่งผลต่อประสิทธิภาพการอ่าน / เขียนบนไดรฟ์อย่างไร

ฉันมีไดรฟ์ที่ฟอร์แมต EXT3 บนเซิร์ฟเวอร์ Linux CentOS นี่คือไดรฟ์ข้อมูลแอปบนเว็บและมีไดเรกทอรีสำหรับบัญชีผู้ใช้ทุกบัญชี (มีผู้ใช้ 25,000 คน) แต่ละโฟลเดอร์มีไฟล์ที่ผู้ใช้อัปโหลด โดยรวมแล้วไดรฟ์นี้มีข้อมูลประมาณ 250GB

การจัดโครงสร้างไดรฟ์กับไดเรกทอรีทั้งหมดเหล่านี้ส่งผลต่อประสิทธิภาพการอ่าน / เขียนของไดรฟ์หรือไม่? มันส่งผลกระทบด้านประสิทธิภาพอื่น ๆ ที่ฉันไม่ทราบหรือไม่

มีอะไรผิดปกติหรือไม่ดีกับโครงสร้างสิ่งนี้หรือไม่? บางทีอาจเป็นทางเลือกที่ผิดของระบบไฟล์?

ฉันเพิ่งลองผสานสองไดรฟ์ข้อมูลและรับรู้ว่า EXT3 ถูก จำกัด ไว้ที่ 32,000 ไดเรกทอรีย่อย นี่ทำให้ฉันสงสัยว่าทำไม ดูเหมือนว่าโง่ที่ฉันสร้างขึ้นด้วยวิธีนี้โดยพิจารณาว่าแต่ละไฟล์มี id ที่ไม่ซ้ำกันซึ่งสอดคล้องกับ id ในฐานข้อมูล อนิจจา ...

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

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

คำตอบนั้นไม่ง่ายอย่างตัวเลือกของระบบไฟล์ ระบบไฟล์ของ Sane หยุดใช้รายการเชิงเส้นสำหรับไดเรกทอรีเมื่อนานมาแล้วซึ่งหมายความว่าจำนวนรายการในไดเรกทอรีจะไม่ส่งผลต่อเวลาในการเข้าถึงไฟล์ ....

ยกเว้นเมื่อมันทำ

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

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

แก้ไข :

ระบบไฟล์ที่ทันสมัยทั้งหมดใช้โครงสร้างข้อมูลที่ดีสำหรับไดเรกทอรีขนาดใหญ่ดังนั้นการดำเนินการครั้งเดียวที่มีการค้นหา inode ของไฟล์ที่ระบุจะค่อนข้างรวดเร็วแม้ในไดเรกทอรีที่มีเนื้อความ

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

ตัวอย่างเช่นสมมติว่าคุณมีไดเรกทอรีที่มีไฟล์นับล้านชื่อเรียกว่า 'foo-000000.txt' ถึง 'foo-999999.txt' และ 'natalieportman.jpeg' เพียงไฟล์เดียว สิ่งเหล่านี้จะรวดเร็ว:

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

สิ่งเหล่านี้จะล้มเหลว แต่ล้มเหลวอย่างรวดเร็วเช่นกัน:

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

สิ่งเหล่านี้จะช้าแม้ว่าพวกเขาจะได้ผลลัพธ์น้อยมากก็ตาม แม้กระทั่งสิ่งที่ล้มเหลวก็ล้มเหลวหลังจากสแกนรายการทั้งหมด:

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

ก่อนอื่นตรวจสอบให้แน่ใจว่าพาร์ติชัน ext3 มีการdir_indexตั้งค่าสถานะ

sudo dumpe2fs /dev/sdaX |grep --color dir_index

หากไม่มีคุณสามารถเปิดใช้งานได้ คุณต้องยกเลิกการต่อเชื่อมระบบไฟล์จากนั้นเรียกใช้:

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

จากนั้นเมานต์ระบบไฟล์

มันไม่ต่างอะไรจนกว่าคุณจะกดชื่อ ext3 32,000 ชื่อต่อการ จำกัด ไดเรกทอรี การอัปเกรดเป็น ext4 สามารถรับสิ่งนั้นได้เช่นเดียวกับผลประโยชน์อื่น ๆ ที่ ext4 มี

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

ทางออกที่ดีกว่าคือการสร้างลำดับชั้นไดเรกทอรีเช่นนี้

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

และหากคุณยังต้องการประสิทธิภาพที่ดีขึ้นคุณสามารถขยายได้หลายระดับ:

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

ระบบเมลส่วนใหญ่ใช้เคล็ดลับนี้กับไฟล์คิวเมล

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

ฉันพัฒนาเซิร์ฟเวอร์หน่วยเก็บข้อมูลเมื่อเร็ว ๆ นี้ซึ่งต้องการสร้างไฟล์หลายสิบล้านไฟล์และหลายแสนไดเรกทอรี ฉันเปรียบเทียบ XFS กับ ext4 และ reiserfs ฉันพบว่าในกรณีของ ext4 นั้นเร็วกว่า XFS เล็กน้อย Reiser น่าสนใจ แต่มีข้อ จำกัด ฉันยังพบว่า ext4 นั้นเร็วกว่า ext3 อย่างมาก

เมื่อคุณได้รับไฟล์จำนวนมากต่อไดเรกทอรีเวลาเปิดไฟล์จะเริ่มแย่ลง ไฟล์ I / O ไม่ได้ เวลาในการลบไฟล์ก็มีผลเช่นกัน อย่างไรก็ตามมันไม่ช้าเกินไปสำหรับ ext4 มันค่อนข้างชัดเจนภายใต้ ext3 แม้ว่า XFS และ ext4 ค่อนข้างเร็วในเรื่องนี้

เมื่อฉันดู XFS ครั้งสุดท้ายและชั่งน้ำหนักข้อดีและข้อเสียของการใช้ XFS บน ext4 ฉันพบรายงานการสูญหายของข้อมูลด้วย XFS ฉันไม่แน่ใจว่าปัญหานี้ยังคงมีอยู่หรือไม่ แต่มันก็ทำให้ฉันกังวลพอที่จะหลีกเลี่ยง ext4 นั้นเป็น fs เริ่มต้นใน Ubuntu จึงชนะได้ง่ายกว่า XFS

ดังนั้นนอกเหนือจากข้อเสนอแนะของ tylerl ซึ่งจะช่วยในมุมมองการจัดการฉันขอแนะนำให้คุณอัพเกรดเป็น ext4 ขีด จำกัด ต่อไดเรกทอรีคือ 64000 รายการที่มี ext4

ประโยชน์อีกอย่างคือเวลา fsck เร็วขึ้นอย่างมาก ฉันไม่เคยมีปัญหาใด ๆ กับการทุจริต

สิ่งที่ดีเกี่ยวกับ ext4 คือคุณสามารถเมานต์วอลุ่ม ext3 เป็น ext4 เพื่อลอง โปรดดู: การโอนย้ายระบบสดจาก ext3 ไปยังระบบไฟล์ ext4

คำพูดจากลิงค์นั้น:

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

ดังนั้นไปข้างหน้าและลอง แนะนำให้คุณสำรองข้อมูลก่อน

มีความแน่นอนจะเป็นผลที่ตามมาจากการทำเช่นนี้ อันแรกจะเป็น IO อ่าน / เขียน นอกเหนือจากนั้นมันเป็นเพียงวิธีที่น่ากลัวมากในการจัดการกับข้อมูลประเภทนั้น (ในระดับนั้น)

ในอดีตฉันใช้ XFS เพื่อหลีกเลี่ยงข้อ จำกัด ของ Ext3 ที่ประสบความสำเร็จ

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

ฉันเห็นผู้ดูแลระบบเรียกใช้ 'find / somepath 2> & 1> / dev / null' ใน cron เป็นประจำเพื่อให้แคชใช้งานได้ดีขึ้นส่งผลให้ประสิทธิภาพดีขึ้น

ฉันมีคำถามและการค้นพบคอขวดที่เป็นไปได้

อันดับแรกนี่คือระบบ CentOS 5 หรือ 6 หรือไม่? เพราะใน 6 เรามีเครื่องมือที่ยอดเยี่ยมที่เรียกว่า blktrace ซึ่งเหมาะสำหรับการวัดผลกระทบในสถานการณ์แบบนี้

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

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

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

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

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

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

มันไม่ใช่ตัวเลือกใน CentOS 5 และไม่แน่ใจว่าเป็นตัวเลือกใน CentOS 6 แต่ฉันมีความรู้สึกว่าการใช้ B tree หรือ B * tree เป็นวิธีแก้ปัญหาเช่น BTRFS จะให้ประสิทธิภาพที่สอดคล้องกัน สถานการณ์ถ้ามีเพียงคนเดียวที่สามารถมอบความไว้วางใจให้กับข้อมูลอันมีค่าของตนด้วยความรู้สึกผิดที่ชัดเจน

แต่ถ้าคุณสามารถจ่ายได้คุณสามารถทดสอบได้