ความหมายของประสิทธิภาพสำหรับไฟล์นับล้านไฟล์ในระบบไฟล์ที่ทันสมัยคืออะไร?

สมมติว่าเรากำลังใช้ ext4 (ด้วย dir_index ที่เปิดใช้งาน) เพื่อโฮสต์ไฟล์ 3M (โดยมีขนาดเฉลี่ย 750KB) และเราจำเป็นต้องตัดสินใจว่าจะใช้รูปแบบโฟลเดอร์ใด

ในโซลูชันแรกเราใช้ฟังก์ชันแฮชกับไฟล์และใช้โฟลเดอร์สองระดับ (เป็น 1 ตัวอักษรสำหรับระดับแรกและ 2 ตัวอักษรถึงระดับที่สอง): ดังนั้นการเป็นfilex.forแฮชเท่ากับabcde1234เราจะเก็บไว้ใน / เส้นทาง / a / bc /abcde1234-filex.for

ในโซลูชันที่สองเราใช้ฟังก์ชันแฮชกับไฟล์และใช้โฟลเดอร์สองระดับ (เป็น 2 ตัวอักษรสำหรับระดับแรกและ 2 ตัวอักษรถึงระดับที่สอง): ดังนั้นการเป็นfilex.forแฮชเท่ากับabcde1234เราจะเก็บไว้ใน / เส้นทาง / ab / de /abcde1234-filex.for

สำหรับวิธีแก้ปัญหาแรกเราจะมีรูปแบบต่อไปนี้ที่/path/[16 folders]/[256 folders]มีค่าเฉลี่ย 732 ไฟล์ต่อโฟลเดอร์ (โฟลเดอร์สุดท้ายที่ไฟล์จะอยู่)

ในขณะที่การแก้ปัญหาที่สองเราจะมี/path/[256 folders]/[256 folders]กับค่าเฉลี่ยของ 45 ไฟล์ต่อโฟลเดอร์

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

นอกจากนี้ยังมีเครื่องมืออะไรบ้างที่เราสามารถใช้ตรวจสอบ / ทดสอบการตั้งค่านี้

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

ความช้านั้นขึ้นอยู่กับการออกแบบระบบไฟล์

ระบบไฟล์ ext4 ใช้B-treeเพื่อเก็บรายการไดเรกทอรี การค้นหาในตารางนี้คาดว่าจะใช้เวลาO (log n)ซึ่งส่วนใหญ่น้อยกว่าตารางเชิงเส้นไร้เดียงสาที่ ext3 และระบบไฟล์ก่อนหน้านี้ใช้ (และเมื่อไม่มี) ไดเรกทอรีนั้นเล็กเกินไปสำหรับ สำคัญจริงๆ)

ระบบไฟล์ XFS ใช้ต้นไม้ B +แทน ข้อได้เปรียบของสิ่งนี้เหนือโต๊ะแฮชหรือ B-tree คือโหนดใด ๆ ที่อาจมีหลายลูกขซึ่งใน XFS bจะแตกต่างกันและอาจสูงถึง 254 (หรือ 19 สำหรับโหนดรูทและตัวเลขเหล่านี้อาจล้าสมัย ) สิ่งนี้ทำให้คุณมีเวลาที่ซับซ้อนของO (log _b n)ซึ่งเป็นการปรับปรุงที่มากมาย

ระบบไฟล์เหล่านี้สามารถจัดการไฟล์ได้หลายหมื่นไฟล์ในไดเรกทอรีเดียวโดย XFS นั้นเร็วกว่า ext4 อย่างมากในไดเรกทอรีที่มีจำนวน inodes เท่ากัน แต่คุณอาจไม่ต้องการไดเรกทอรีเดียวที่มี 3M inodes เช่นเดียวกับต้นไม้ B + การค้นหาอาจใช้เวลาสักครู่ นี่คือสิ่งที่นำไปสู่การสร้างไดเรกทอรีในลักษณะนี้ตั้งแต่แรก

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

จากประสบการณ์ของฉันหนึ่งในปัจจัยการปรับสเกลคือขนาดของ inodes ที่กำหนดกลยุทธ์การแบ่งชื่อแบบแฮช

ตัวเลือกทั้งสองที่คุณเสนอนั้นสร้างรายการ inode ได้สูงสุดสามรายการสำหรับแต่ละไฟล์ที่สร้างขึ้น นอกจากนี้ไฟล์ 732 ไฟล์จะสร้าง inode ที่ยังน้อยกว่า 16KB ปกติ สำหรับฉันนี่หมายถึงตัวเลือกใดตัวเลือกหนึ่งจะทำงานเหมือนกัน

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

แน่นอนว่าตัวเลือกใดตัวเลือกหนึ่งจะช่วยลดจำนวนไฟล์ในไดเรกทอรีเป็นสิ่งที่สมเหตุสมผลสำหรับ xfs หรือ ext4 หรือระบบไฟล์ใด ๆ ไม่ชัดเจนซึ่งดีกว่าจะต้องทดสอบเพื่อบอก

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

hdparmการทำ I / O อย่างยั่งยืนนั้นไม่มีประโยชน์ มันจะไม่แสดง I / Os ขนาดเล็กจำนวนมากหรือรายการไดเรกทอรียักษ์ที่เชื่อมโยงกับไฟล์จำนวนมาก

หนึ่งในปัญหาคือวิธีการสแกนโฟลเดอร์

ลองนึกภาพวิธี Java ที่เรียกใช้การสแกนในโฟลเดอร์

จะต้องจัดสรรหน่วยความจำจำนวนมากและยกเลิกการจัดสรรในช่วงเวลาสั้น ๆ ซึ่งหนักมากสำหรับ JVM

วิธีที่ดีที่สุดคือจัดโครงสร้างโฟลเดอร์ตามวิธีที่แต่ละไฟล์อยู่ในโฟลเดอร์เฉพาะเช่นปี / เดือน / วัน

วิธีการสแกนแบบเต็มรูปแบบก็คือสำหรับแต่ละโฟลเดอร์มีฟังก์ชั่นการทำงานหนึ่งเดียวดังนั้น JVM จะออกจากฟังก์ชั่นยกเลิกการจัดสรรแรมและรันอีกครั้งในโฟลเดอร์อื่น

นี่เป็นเพียงตัวอย่าง แต่การมีโฟลเดอร์ขนาดใหญ่เช่นนี้ก็ไม่สมเหตุสมผล

ฉันมีปัญหาเดียวกัน พยายามจัดเก็บไฟล์หลายล้านไฟล์ในเซิร์ฟเวอร์ Ubuntu ใน ext4 สิ้นสุดการใช้งานการวัดประสิทธิภาพของฉันเอง พบว่าไดเรกทอรีแบนทำงานได้ดีขึ้นในขณะที่ใช้งานง่ายกว่า:

เขียนบทความ