ฉันมีเซิร์ฟเวอร์สำรอง Ubuntu 16.04 พร้อม HDD 8x10TB ผ่าน SATA 3.0 Backplane 8 Harddisks นั้นประกอบกับ RAID6 ซึ่งเป็นระบบไฟล์ EXT4 ที่ใช้งานอยู่ ระบบไฟล์นี้จัดเก็บไฟล์ขนาดเล็กจำนวนมากที่มีการดำเนินการ SEEK จำนวนมาก แต่มีปริมาณงาน IO ต่ำ ในความเป็นจริงมีไฟล์ขนาดเล็กจำนวนมากจากเซิร์ฟเวอร์ที่แตกต่างกันซึ่งได้รับ snappshotted ผ่าน rsnapshot ทุกวัน (INODES หลายโดยตรงไปยังไฟล์เดียวกันฉันมีประสิทธิภาพที่ดีมากตั้งแต่ระบบไฟล์ (60TB สุทธิ) เกินการใช้งาน 50% ในขณะนี้ การใช้งานอยู่ที่ 75% และ

du -sch /backup-root/

ใช้เวลาหลายวัน (!) เครื่องมี 8 คอร์และ RAM 16G RAM นั้นถูกใช้งานอย่างเต็มที่โดย OS filesystem Cache, 7 จาก 8 คอร์ว่างตลอดเวลาเนื่องจาก IOWAIT

Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags:         signed_directory_hash 
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              912203776
Block count:              14595257856
Reserved block count:     0
Free blocks:              4916228709
Free inodes:              793935052
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         2048
Inode blocks per group:   128
RAID stride:              128
RAID stripe width:        768
Flex block group size:    16
Filesystem created:       Wed May 31 21:47:22 2017
Last mount time:          Sat Apr 14 18:48:25 2018
Last write time:          Sat Apr 14 18:48:18 2018
Mount count:              9
Maximum mount count:      -1
Last checked:             Wed May 31 21:47:22 2017
Check interval:           0 (<none>)
Lifetime writes:          152 TB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               256
Required extra isize:     28
Desired extra isize:      28
Journal inode:            8
First orphan inode:       513933330
Default directory hash:   half_md4
Directory Hash Seed:      5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup:           inode blocks
Journal features:         journal_incompat_revoke journal_64bit
Journal size:             128M
Journal length:           32768
Journal sequence:         0x00c0b9d5
Journal start:            30179

ฉันไม่มีประสบการณ์กับการใช้ระบบไฟล์ชนิดนี้ ฉันต้องเลือกตัวเลือกอะไร ระบบไฟล์ใดที่จะทำงานได้ดีขึ้นในสถานการณ์นี้ มีตัวเลือกใดบ้างที่เกี่ยวข้องกับ RAM สำหรับตัวเลือกการแคชอื่นที่ไม่ใช่ OS-build-in

คุณจะจัดการไฟล์ขนาดเล็กจำนวนมากในแอสเซมบลี RAID ขนาดใหญ่ได้อย่างไร

ขอบคุณเซบาสเตียน

ฉันมีการตั้งค่าที่คล้ายกัน (แม้ว่าจะเล็กกว่า) โดยมีดิสก์ขนาด 12x2TB ในอาร์เรย์ RAID6 ที่ใช้เพื่อจุดประสงค์เดียวกัน ( rsnapshotเซิร์ฟเวอร์สำรอง)

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

ความเชื่องช้าของคุณเกิดจากเมตาดาต้าระบบไฟล์ที่อยู่ในบล็อกที่ห่างไกลมาก (ในแง่ LBA) ทำให้เกิดการค้นหาหลายอย่าง ในฐานะที่เป็นดิสก์ 7.2K RPM ปกติมีประมาณ ~ 100 IOPS คุณสามารถดูว่าจำเป็นต้องโหลดชั่วโมงเมตาดาต้ากี่ชั่วโมงถ้าไม่ใช่วันเพื่อโหลดข้อมูลเมตาทั้งหมด

สิ่งที่คุณสามารถลอง (ไม่ทำลาย) แก้ไขสถานการณ์ให้ดีขึ้น:

• ให้แน่ใจว่าจะไม่ได้มีmlocate/slocateการจัดทำดัชนีของคุณ/backup-root/(คุณสามารถใช้สิ่งอำนวยความสะดวก prunefsเพื่อหลีกเลี่ยงที่) หรือเมตาดาต้าแคช trashing จะทำให้การ severly เวลาการสำรองข้อมูลของคุณ
• ด้วยเหตุผลเดียวกันหลีกเลี่ยงการทำงานในdu /backup-root/หากจำเป็นให้เรียกใช้duเฉพาะโฟลเดอร์ย่อยที่สนใจเท่านั้น
• ต่ำกว่าvfs_cache_pressureจากค่าเริ่มต้น (100) เป็นค่าที่อนุรักษ์มากกว่า (10 หรือ 20) สิ่งนี้จะสั่งให้เคอร์เนลต้องการการแคชข้อมูลเมตามากกว่าการแคชข้อมูล ในทางกลับกันสิ่งนี้ควรเร่งความเร็วในการrsnapshot/rsyncค้นพบ
• คุณสามารถลองเพิ่มอุปกรณ์แคช writethrough เมเช่นผ่านlvmcacheหรือbcache อุปกรณ์เมตาดาต้านี้ควรเป็น SSD อย่างชัดเจน
• เพิ่ม RAM ที่พร้อมใช้งานของคุณ
• ในขณะที่คุณใช้ ext4 โปรดระวังปัญหาการจัดสรร inode (อ่านที่นี่เพื่อเป็นตัวอย่าง) นี่ไม่ใช่ความสัมพันธ์โดยตรงกับประสิทธิภาพ แต่เป็นปัจจัยสำคัญเมื่อมีไฟล์จำนวนมากในระบบไฟล์แบบ ext

สิ่งอื่น ๆ ที่คุณสามารถลอง - แต่สิ่งเหล่านี้เป็นการปฏิบัติการทำลายล้าง

• ใช้ XFS พร้อมทั้งชุด-ftypeและ-finobtตัวเลือก
• ใช้ ZFS บน Linux (ZoL) ด้วยการบีบอัด ARC และprimarycache=metadataการตั้งค่า (และอาจเป็น L2ARC สำหรับแคชแบบอ่านอย่างเดียว)

ระบบไฟล์นี้จัดเก็บไฟล์ขนาดเล็กจำนวนมากที่มีการดำเนินการ SEEK จำนวนมาก แต่มีปริมาณงาน IO ต่ำ

🎉

นี่คือสิ่งที่ดึงดูดผู้คนจำนวนมากในปัจจุบัน อนิจจา FSes ทั่วไปไม่ได้ปรับขนาดได้ดีที่นี่ ฉันสามารถให้คำแนะนำเพียงไม่กี่ข้อเกี่ยวกับการตั้งค่าที่คุณมีอยู่แล้ว: EXT4 over RAID-6 บน HDD :

1. ลดvm.vfs_cache_pressureลงพูดถึง 1 มันจะเปลี่ยนอคติการแคชต่อการรักษาข้อมูลเมตาเพิ่มเติม (inode, dentry) แทนที่จะเป็นข้อมูลและควรมีผลในเชิงบวกในการลดจำนวนการค้นหา
2. เพิ่มRAM มากกว่า แม้ว่ามันอาจดูแปลกสำหรับเซิร์ฟเวอร์ที่ไม่ได้เรียกใช้แอพพิกกี้ใด ๆ โปรดจำไว้ว่า: วิธีเดียวที่จะลดการค้นหาคือการเก็บข้อมูลเมตาได้มากขึ้นในที่จัดเก็บข้อมูลที่รวดเร็วกว่าเนื่องจากคุณมี 16 GB เท่านั้นดูเหมือนว่า เพิ่มจำนวนแรม
3. อย่างที่ฉันได้กล่าวไปแล้วว่า EXT4 ไม่ใช่ตัวเลือกที่ดีสำหรับกรณีการใช้งานที่คุณมี แต่คุณยังสามารถใช้คุณลักษณะบางอย่างเพื่อบรรเทาความเจ็บปวด:
   • เจอร์นัลภายนอกได้รับการสนับสนุนดังนั้นคุณสามารถลองเพิ่ม SSD (มิเรอร์ที่ดีกว่า) และวางเจอร์นัลนั้น ดู " ext4: คำเตือนวารสารภายนอก "
   • ลองสลับโหมดเจอร์นัลเป็น "กำลังบันทึกข้อมูลทั้งหมด" ด้วยการติดตั้งด้วยdata=journal
4. ลองย้ายไฟล์นอกขอบเขต FS เดียว ตัวอย่างเช่นหากคุณมี LVM-2 ที่นี่คุณสามารถสร้างไดรฟ์ข้อมูลที่มีขนาดน้อยลงและใช้มันในช่วงเวลาหนึ่งจากนั้นเมื่อมันเต็มให้สร้างอีกอันหนึ่งขึ้นเรื่อย ๆ
   • หากคุณไม่มี LVM-2 คุณสามารถลองทำด้วย / dev / loop ได้ แต่มันไม่สะดวกและอาจมีประสิทธิภาพน้อยกว่า

UPD : เนื่องจากมันกลายเป็นLinux Software RAID (LSR) RAID-6, ต่อไปนี้เป็นรายการเพิ่มเติม:

5. LSR มีตัวเลือกการปรับแต่งที่คนจำนวนมากดูเหมือนจะมองข้าม
   • แคชลายที่สามารถตั้งค่าได้สูงสุด: echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size- แต่ทำอย่างนี้ด้วยความระมัดระวัง (ใช้ค่าที่น้อยลงถ้าจำเป็น) เนื่องจากขนาดมีขนาดหลายเท่าและขึ้นอยู่กับขนาดของก้อนที่คุณเลือกจะใช้ RAM ในปริมาณที่แตกต่างกัน
   • สมุดรายวันภายนอกซึ่งสามารถใช้กับ SSD ที่มิร์เรอร์เหล่านั้นได้ ( แต่ปัจจุบันอุปกรณ์ MD ที่สร้างสมุดรายวันที่ไม่มีการแปลงให้ใช้หนึ่งรายการ )

- นั่นอาจเป็นสิ่งที่สามารถปรับปรุงได้โดยไม่ต้องมีการออกแบบใหม่

ฉันมีประสิทธิภาพต่ำมากเนื่องจากระบบไฟล์ (60TB สุทธิ) เกินการใช้งาน 50% ในขณะนี้การใช้งานอยู่ที่ 75%

นั่นเป็นปัญหาที่ร้ายแรงมากเนื่องจากระดับการใช้พื้นที่ดิสก์สูงนั้นทำให้การกระจายตัวของข้อมูลแย่ลงเท่านั้น และการกระจายตัวมากขึ้นหมายถึงการแสวงหามากขึ้น ไม่น่าแปลกใจว่าทำไมมันถึงให้ประสิทธิภาพที่ยอมรับได้มากขึ้นหรือน้อยลงก่อนที่จะถึง 50% คู่มือจำนวนมากมีคำแนะนำที่ชัดเจนเพื่อไม่ให้ FSes โตขึ้นหลัง 75-80%

RAID6 ไม่ได้ช่วยอะไรคุณมากในกรณีนี้บางอย่างเช่น ZFS อาจเปิดใช้งานเมทาดาทาและการเข้าถึงไดเรกทอรีที่รวดเร็วยิ่งขึ้นขณะเดียวกันก็รักษาความเร็วไว้เท่าเดิม

RAID-6 Stripe Drive ดังนั้น IO ทั้งหมดจึงไปยังไดรฟ์ทั้งหมด มันไม่มีประสิทธิภาพเลยทีเดียวสำหรับไฟล์เล็ก ๆ อย่างไรก็ตามนี่อาจไม่ใช่ปัญหาหลักของคุณซึ่งก็คือ ...

Ext4 ไม่เหมาะสำหรับระบบไฟล์ขนาดใหญ่ที่มีไฟล์นับล้าน ใช้XFS ฉันมีระบบไฟล์ XFS ที่ทำงานได้สูงถึง 1,2 PB และมากถึง 1 พันล้านไฟล์ไม่มีปัญหา เพียงแค่ใช้ XFS

ขอบคุณทุกคนที่ให้คำตอบสำหรับคำถามของฉัน

นี่คือวิธีที่ฉันแก้ไขมัน:

ก่อนอื่นฉันเพิ่ม RAM สูงสุดในบอร์ด น่าเสียดายที่บอร์ดรองรับ RAM สูงสุด 64GB เท่านั้น ฉันสังเกตพฤติกรรมหลังจากการขยายตัวและมันก็น่าผิดหวัง แม้ว่า RAM ที่มีอยู่ทั้งหมดจะถูกใช้สำหรับ IO Cache แต่ประสิทธิภาพของ RSNAPSHOT-Backup นั้นไม่ได้ปรับปรุงให้ดีขึ้น

ดังนั้นฉันต้องดึงคทาขนาดใหญ่ ฉันเพิ่มดิสก์ NVME 1TB สองแผ่นและประกอบเข้ากับ RAID 1 RAID 6 ซึ่งประกอบด้วย HDD 10 x 10TB ได้ถูกถอดออกเป็นหนึ่ง RAID 1 (ประกอบด้วย 2x10TB HDD, ext4) และ RAID 5 หนึ่งตัว (ประกอบด้วย 6x10TB HDD) RAID 1 ตอนนี้มีระบบปฏิบัติการและสำเนาการทำงานของเซิร์ฟเวอร์ (ซึ่งได้รับการซิงค์ 4 ครั้งต่อวันในไดรฟ์นี้)

RAID5 เป็นอุปกรณ์ที่สำรองไว้สำหรับ BCACHE ซึ่งสนับสนุนโดย NVME-RAID 1 และจัดรูปแบบด้วย ext4 ไดรฟ์นี้มีสำเนา RSNAPSHOT ทุกคืนไฟล์จะถูกซิงค์จาก RAID1 ถึง RAID5 ซึ่งแบ่ง IO-throughput ของ RAID5 ลงครึ่งหนึ่งเมื่อเทียบกับ RAID6 ในอดีตซึ่งมีสำเนาการทำงานและสแน็ปช็อตสำรอง ขอบคุณ BCache ไม่ใช่เพียงไฟล์เดียวเท่านั้นที่ถูกเขียนไปยังดิสก์ แต่การเปลี่ยนแปลงทั้งหมดในบล็อกเดียวจะถูกเขียนเพียงครั้งเดียวแม้ว่าจะมีการเปลี่ยนแปลงไฟล์เดี่ยวหลายอย่างก็ตาม นี่ทำให้ IOPS ลดลงอีกใน HDD

ในที่สุดฉันเปลี่ยนการตั้งค่า RSnapshot ของฉัน ก่อนหน้านี้มี 31 สแน็ปช็อตรายวันและ 18 สแน็ปช็อตรายเดือนซึ่งส่งผลให้มีการสำรองข้อมูล 49 รุ่น ตอนนี้ฉันมี 7d / 4w / 12m / 1y-Design แบบคลาสสิกซึ่งลดปริมาณการสำรองข้อมูลลงเหลือ 24

หลังจากการเปลี่ยนแปลงเหล่านี้ (และด้วย RAM 64GB ที่กล่าวถึงข้างต้น) ระยะเวลาสำหรับสแนปชอตหนึ่งรายการลดลงจาก ~ 20 ชม. ถึง 1.5 ชั่วโมง อุปกรณ์ BCache นั้นมีอัตราการใช้งานแคช 82% (หลังจากใช้งานปกติ 6 สัปดาห์)

ภารกิจเสร็จสมบูรณ์. ขอบคุณทุกท่านสำหรับความคิดและการป้อนข้อมูลของคุณ