ระบบไฟล์ Linux ประสิทธิภาพสูงที่สุดสำหรับการจัดเก็บไฟล์ขนาดเล็กจำนวนมาก (HDD ไม่ใช่ SSD) คืออะไร

43

ฉันมีแผนผังไดเรกทอรีที่มีไฟล์ขนาดเล็กจำนวนมากและไฟล์ขนาดใหญ่จำนวนเล็กน้อย ขนาดเฉลี่ยของไฟล์ประมาณ 1 กิโลไบต์ มีไฟล์ 210158 และไดเรกทอรีในต้นไม้ (จำนวนนี้ได้รับจากการทำงานfind | wc -l)

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

ระบบไฟล์ที่ฉันลอง (ext4, btrfs) มีปัญหากับการวางตำแหน่งไฟล์บนดิสก์ เมื่อเวลาผ่านไปนานกว่าตำแหน่งทางกายภาพของไฟล์บนดิสก์ (สื่อที่หมุนไม่ได้เป็นดิสก์สถานะของแข็ง) มีการกระจายแบบสุ่มมากขึ้น ผลกระทบเชิงลบของการกระจายแบบสุ่มนี้คือระบบไฟล์เริ่มช้าลง (เช่น: ช้ากว่าระบบไฟล์ใหม่ถึง 4 เท่า)

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

linux filesystems performance

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

— Marcin

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

— Nikhil Mulley

มี zfs สัตว์ออนไลน์ใหม่บน Linux ที่มีอยู่ในโหมดเนทิฟและการใช้งานฟิวส์หากคุณต้องการดู

— Nikhil Mulley

ฉันลอง zfs บน linux หนึ่งครั้งมันค่อนข้างไม่เสถียร จัดการเพื่อล็อคระบบไฟล์อย่างสมบูรณ์ค่อนข้างบ่อย Box ใช้งานได้ แต่การเข้าถึง FS จะหยุดทำงาน

— แพทริค

โพสต์ที่คล้ายกันserverfault.com/questions/6711/…

— Nikhil Mulley

47

ประสิทธิภาพ

ฉันเขียน Benchmark ขนาดเล็ก (ที่มา ) เพื่อค้นหาว่าระบบไฟล์ใดทำงานได้ดีที่สุดกับไฟล์ขนาดเล็กนับแสน:

สร้างไฟล์ 300,000 ไฟล์ (512B ถึง 1536B) ด้วยข้อมูลจาก / dev / urandom
เขียนไฟล์สุ่ม 30000 ครั้งและเปลี่ยนขนาด
อ่านไฟล์ลำดับ 30000
อ่านไฟล์สุ่ม 30000
ลบไฟล์ทั้งหมด
ซิงค์และวางแคชหลังจากทุกขั้นตอน

ผลลัพธ์ (เวลาเฉลี่ยเป็นวินาที, ลด = ดีกว่า):

Using Linux Kernel version 3.1.7
Btrfs:
    create:    53 s
    rewrite:    6 s
    read sq:    4 s
    read rn:  312 s
    delete:   373 s

ext4:
    create:    46 s
    rewrite:   18 s
    read sq:   29 s
    read rn:  272 s
    delete:    12 s

ReiserFS:
    create:    62 s
    rewrite:  321 s
    read sq:    6 s
    read rn:  246 s
    delete:    41 s

XFS:
    create:    68 s
    rewrite:  430 s
    read sq:   37 s
    read rn:  367 s
    delete:    36 s

ผลลัพธ์:
ในขณะที่ Ext4 มีประสิทธิภาพโดยรวมที่ดี ReiserFS นั้นรวดเร็วมากในการอ่านไฟล์ตามลำดับ มันกลับกลายเป็นว่าXFS ช้ากับไฟล์ขนาดเล็กจำนวนมาก - คุณไม่ควรใช้มันสำหรับกรณีการใช้งานนี้

ปัญหาการกระจายตัว

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

อ่านเพิ่มเติม

Arch Wiki มีบทความที่ยอดเยี่ยมเกี่ยวกับประสิทธิภาพของระบบไฟล์:

https://wiki.archlinux.org/index.php/Beginner%27s_Guide#Filesystem_types

https://wiki.archlinux.org/index.php/Maximizing_Performance#Storage_devices

— taffer
แหล่งที่มา

4

คุณควรระบุเวอร์ชันของเคอร์เนลที่คุณอ้างอิงจากการเปรียบเทียบ XFS มีการปรับปรุงความเร็วที่สำคัญอย่างมากในเมล็ดล่าสุด (คิดว่าเป็น 2.6.31 แต่ไม่ต้องอ้างถึงฉัน)

— แพทริค

1

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

— psusi

1

นั่นเป็นเรื่องจริงสำหรับระบบไฟล์ใด ๆ นั่นคือเหตุผลที่แอปพลิเคชันใช้สิ่งต่าง ๆ เช่น fsync ()

— psusi

2

@affer มันเป็น การทำธุรกรรมมีผลเช่นเดียวกับวารสารที่ทำในระบบไฟล์อื่น ๆ : พวกเขาปกป้องเมตาดาต้า fs ในทางทฤษฎีสามารถใช้แอปพลิเคชั่นในแบบที่คุณอธิบาย แต่ขณะนี้ยังไม่มี API ที่อนุญาตให้แอปพลิเคชันเปิดและปิดธุรกรรม

— psusi

1

@taffer "เกณฑ์มาตรฐานล่าสุด" ของคุณมาจากเดือนเมษายน 2558 อายุเกินสามปีและใช้ XFS ที่มีตัวเลือกเริ่มต้นเท่านั้น ก่อนหน้านี้ xfsprogs 3.2.3 ซึ่งทำให้ XFS v5 เป็นค่าเริ่มต้นและประโยชน์ทั้งหมดที่จะได้รับ นอกจากนี้ยังไม่ได้จัดรูปแบบด้วย -m finobt = 1 ซึ่งเป็นตัวเปลี่ยนเกมสำหรับประสิทธิภาพ XFS ที่มีไฟล์ขนาดเล็กและการอัปเดตข้อมูลเมตาจำนวนมาก ไม่ไม่มีกระสุนเงิน แต่การอ้างอิงความคิดเห็นของคุณเกี่ยวกับการวัดประสิทธิภาพแบบเก่านั้นไม่ฉลาดโดยเฉพาะอย่างยิ่งเมื่อคุณสมบัติการเปลี่ยนประสิทธิภาพที่สำคัญถูกเพิกเฉยไม่สามารถใช้งานได้หรือถูกปิดใช้งาน

— โจดี้ลีบรูชอน

7

ฉันใช้ ReiserFS สำหรับงานนี้มันถูกสร้างขึ้นมาเพื่อการจัดการไฟล์ขนาดเล็กจำนวนมากโดยเฉพาะ มีข้อความที่อ่านง่ายเกี่ยวกับเรื่องนี้ที่ funtoo wiki

ReiserFS ยังมีโฮสต์ของฟีเจอร์ที่มุ่งพัฒนาประสิทธิภาพของไฟล์ขนาดเล็กโดยเฉพาะ ซึ่งแตกต่างจาก ext2, ReiserFS ไม่จัดสรรพื้นที่เก็บข้อมูลในการแก้ไขหนึ่ง k หรือสี่บล็อก k แต่สามารถจัดสรรขนาดที่แน่นอนได้ตามต้องการ

— บาร์น
แหล่งที่มา

1

มีปัญหาด้านความมั่นคงเช่นกันกับ ReiserFS - ดังนั้น RH และ SuSE จึงลดลง FS นั้น จากหลักการ (BTree-based-FS) BTRFS ควรเทียบเคียง

— นิลส์

6

ประสิทธิภาพ ext4 ลดลงหลังจาก 1-2 ล้านไฟล์ในไดเรกทอรี ดูหน้านี้http://genomewiki.ucsc.edu/index.php/File_system_performanceสร้างโดย Hiram Clawson ที่ UCSC

— แม็กซ์
แหล่งที่มา

0

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

นอกจากนี้ XFS ยังรองรับการจัดเรียงข้อมูลออนไลน์อีกด้วย แม้ว่าจะใช้เทคนิคการจัดสรรล่าช้าซึ่งส่งผลให้การกระจายตัวน้อยกว่า (เทียบกับระบบไฟล์อื่น ๆ ) เพื่อเริ่มต้นด้วย

— แพทริค
แหล่งที่มา

20

XFS ถูกบันทึกไว้ว่าทำงานได้ดีมากในสถานการณ์เช่นนี้ [อ้างจำเป็น]

— taffer

8

Ehm, xfs นั้นเป็นที่รู้จักอย่างดีในทางตรงกันข้าม: ทำงานได้ดีกับไฟล์ขนาดใหญ่ แต่ก็ไม่ได้ดีเหมือนกัน! ดูตัวอย่างมาตรฐานที่ละเอียดถี่ถ้วนนี้ (หรือข้ามไปที่ข้อสรุปในหน้า 10 ^^): ilsistemista.net/index.php/linux-a-unix/ …

— Levite

1

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

— Patrick

2

ที่เดียวที่ XFS นั้นดีกว่าจริง ๆ มีการดำเนินการอ่าน / เขียนแบบสุ่ม (ยังคงแปลกที่รูปแบบการอ่านแบบสุ่มอย่างแท้จริงบนดิสก์เชิงกลสามารถรับ 10MB / s - ดูเหมือนว่าฉันชอบการเพิ่มประสิทธิภาพบางอย่างที่ไม่ได้บินในโลกแห่งความเป็นจริง (imho)) ในขณะที่หน้า 7 มันแสดงเพียงสิ่งที่ฉันพูดก่อนหน้านี้ XFS ดีมากในการจัดการไฟล์ขนาดใหญ่! ดูหน้า 3 และ 5 โดยเฉพาะใน 3 ที่คุณเห็นว่าจัดการไฟล์ขนาดเล็กอย่างชัดเจนไม่ดีเท่า ext! ฉันไม่มีอะไรเทียบกับ XFS แต่จากสิ่งที่คุณพบได้ทุกที่มันไม่ได้เป็น optiom ที่ดีที่สุดสำหรับไฟล์ขนาดเล็กจำนวนมากนั่นคือทั้งหมดที่ฉันพูด!

— Levite

5

XFS อาจช้ามากเมื่อพูดถึงไฟล์ขนาดใหญ่หากไฟล์เหล่านี้ขยายแบบสุ่ม / ช้าด้วยชิ้นเล็ก ๆ เป็นเวลานาน ( syslogdรูปแบบทั่วไป) ตัวอย่างเช่นที่ด้านข้างของฉันใน XFS บนการตั้งค่า MD ที่ฉันเพิ่งสังเกตเห็นว่าการลบไฟล์ 1.5 GB ใช้เวลา 4.75 นาที (!) ในขณะที่ดิสก์ไดรฟ์ถูก จำกัด ที่ 100 ธุรกรรม / s ในอัตราการเขียน มากกว่า 2 MB / s สิ่งนี้ยังส่งผลต่อประสิทธิภาพของการดำเนินการ IO แบบขนานอื่น ๆ ในไดรฟ์เดียวกันไม่ดีเนื่องจากไดรฟ์นั้นมีขนาดสูงสุดแล้ว ไม่เคยเห็นอะไรแบบนั้นใน FS อื่น ๆ (หรือถูกทดสอบในการวัดประสิทธิภาพ)

— Tino