นี่คือการติดตามเพื่อ: เครือข่ายความเร็วสูงเขียนด้วยพื้นที่เก็บข้อมูลขนาดใหญ่. การตั้งค่ามีการเปลี่ยนแปลงอย่างเห็นได้ชัด
ฉันมีสระว่ายน้ำด้วยอันเดียว จู่โจม-z2
ด้วย 6 ไดรฟ์ ไดรฟ์ Exos X18 CMR ทั้งหมด โดยใช้ ฟิโอ
และการทดสอบด้วยตนเอง ฉันรู้ว่าอาร์เรย์สามารถรองรับการเขียนตามลำดับได้ประมาณ 800 MB/s โดยเฉลี่ย ซึ่งถือว่าดีและสอดคล้องกับประสิทธิภาพที่คาดหวังของอาร์เรย์นี้ ตัวเครื่องเป็น Ryzen5 Pro 2400 GE (4C/8T, 3.8 GHz boost) พร้อม 32G ECC RAM, NVMe boot/system drive และ 2x10Gbps ethernet ports (Intel x550-T2) ฉันใช้ระบบ Arch ที่ทันสมัยด้วย zfs 2.1.2-1
กรณีการใช้งานของฉันคือไฟล์เก็บถาวรวิดีโอที่มีขนาดใหญ่เป็นส่วนใหญ่ (~30G) เขียนครั้งเดียว อ่านครั้งเดียว บีบอัดวิดีโอ ฉันปิดการใช้งาน เวลา
, ชุด ขนาดบันทึก=1M
, ชุด การบีบอัด = ปิด
และ ลบข้อมูล = ปิด
เนื่องจากข้อมูลไม่สามารถบีบอัดได้จริง และการทดสอบพบว่าประสิทธิภาพแย่ลงด้วย การบีบอัด = lz4
กว่า ปิด
แม้จะมีสิ่งที่อินเทอร์เน็ตพูดและไม่มีข้อมูลที่ซ้ำกันโดยการออกแบบ พูลนี้แชร์ผ่านเครือข่ายผ่าน Samba ฉันได้ปรับแต่งเครือข่ายและ Samba ของฉันจนถึงจุดที่การถ่ายโอนจาก NVMe NTFS บนเครื่องที่ใช้ Windows ไปยัง NVMe ext4 ถึง 1GB/s นั่นคือใกล้เคียงกับการอิ่มตัวของลิงก์ 10 Gbps ด้วย 9K Jumbo Frames
ที่นี่ฉันพบปัญหา ฉันต้องการที่จะโอนไฟล์เก็บถาวรวิดีโอ 30G ทั้งหมดที่ความเร็ว 1GB/s ไปยัง จู่โจม-z2
อาร์เรย์ที่รองรับการเขียนตามลำดับได้ 800 MB/s เท่านั้น แผนของฉันคือใช้หน้าสกปรกตาม RAM เพื่อดูดซับการรั่วไหลและปล่อยให้มันล้างข้อมูลลงดิสก์หลังจากการถ่ายโอน "เสร็จสิ้น" ในฝั่งไคลเอ็นต์ ฉันคิดว่าทั้งหมดที่ฉันต้องการก็คือ (1024-800)*30~=7G
ของหน้าสกปรกใน RAM ที่สามารถล้างออกไปยังดิสก์ได้ภายใน 10 วินาทีหลังจากการถ่ายโอนเสร็จสิ้น ฉันเข้าใจนัยของความสมบูรณ์ของข้อมูลในเรื่องนี้ และยอมรับความเสี่ยงได้ เนื่องจากฉันสามารถถ่ายโอนไฟล์ได้อีกครั้งในภายหลังเป็นเวลาไม่เกินหนึ่งเดือน ในกรณีที่ไฟฟ้าดับทำให้ไฟล์สูญหายหรือไม่สมบูรณ์
อย่างไรก็ตาม ฉันไม่สามารถให้ ZFS ทำงานในแบบที่ฉันคาดไว้ได้... ฉันได้แก้ไขของฉันแล้ว /etc/modprobe.d/zfs.conf
ไฟล์เช่นนั้น:
ตัวเลือก zfs zfs_dirty_data_max_max=25769803776
ตัวเลือก zfs zfs_dirty_data_max_max_percent=50
ตัวเลือก zfs zfs_dirty_data_max=25769803776
ตัวเลือก zfs zfs_dirty_data_max_percent=50
ตัวเลือก zfs zfs_delay_min_dirty_percent=80
ฉันได้วิ่งที่เหมาะสม mkinitcpio -P
คำสั่งเพื่อรีเฟรช initramfs ของฉันและยืนยันว่ามีการใช้การตั้งค่าหลังจากรีบูต:
# arc_summary | grep สกปรก_data
zfs_dirty_data_max 25769803776
zfs_dirty_data_max_max 25769803776
zfs_dirty_data_max_max_percent 50
zfs_dirty_data_max_percent 50
zfs_dirty_data_sync_percent 20
เช่น. ฉันตั้งค่าหน้าสกปรกสูงสุดเป็น 24G ซึ่งมากกว่า 7G ที่ฉันต้องการ และกดค้างไว้เพื่อเริ่มเขียนล่าช้าจนกว่าจะใช้ไป 80% เท่าที่ฉันเข้าใจ พูลควรสามารถดูดซับ 19G ลงใน RAM ก่อนที่มันจะเริ่มผลักดันการเขียนกลับจากไคลเอนต์ (Samba) ด้วยเวลาแฝง
อย่างไรก็ตามสิ่งที่ฉันสังเกตการเขียนจากไคลเอนต์ Windows คือหลังจากผ่านไปประมาณ 16 วินาทีที่ความเร็วในการเขียน ~1 GB/s ประสิทธิภาพการเขียนจะตกลงจากหน้าผา (ไอโอสแตท
ยังคงแสดงดิสก์ที่ทำงานหนักเพื่อล้างข้อมูล) ซึ่งฉันสันนิษฐานได้ว่าเป็นกลไกการย้อนกลับสำหรับการควบคุมปริมาณการเขียนของ ZFS อย่างไรก็ตาม สิ่งนี้ไม่มีเหตุผล เพราะอย่างน้อยที่สุดแม้ว่าจะไม่มีอะไรถูกล้างออกในช่วง 16 วินาทีก็ตาม มันควรจะถูกกำหนดใน 3 วินาทีต่อมานอกจากนี้ หลุดอีกครั้งในตอนท้าย ดูภาพ: [[https://i.stack.imgur.com/Yd9WH.png]
ฉันได้ลองปรับ zfs_dirty_data_sync_percent
เพื่อเริ่มเขียนก่อนหน้านี้เนื่องจากบัฟเฟอร์หน้าสกปรกมีขนาดใหญ่กว่าค่าเริ่มต้นมาก และฉันได้ลองปรับ io scaling ที่ใช้งานอยู่ด้วย zfs_vdev_async_write_active_{นาที,สูงสุด}_dirty_percent
เพื่อเริ่มต้นเร็วขึ้นและเขียนเร็วขึ้นด้วยบัฟเฟอร์สกปรกขนาดใหญ่ ทั้งสองนี้ขยับตำแหน่งของหน้าผาเล็กน้อย แต่ไม่ใกล้เคียงกับที่ฉันคาดไว้
คำถาม:
- ฉันเข้าใจผิดว่าความล่าช้าในการควบคุมการเขียนทำงานอย่างไร
- สิ่งที่ฉันพยายามทำเป็นไปได้ไหม
- ถ้าอย่างนั้น ฉันทำอะไรผิด?
ใช่ ฉันรู้ ฉันกำลังไล่ตามสองสามวินาทีอย่างแท้จริง และจะไม่มีวันชดใช้ความพยายามที่เสียไปในการบรรลุเป้าหมายนี้ ไม่เป็นไร มันเป็นเรื่องส่วนตัวระหว่างฉันกับ ZFS ณ จุดนี้ และเป็นเรื่องของหลักการ ;)