เหตุใดกลุ่ม ZFS ของฉันจึงใช้เวลา 97% ในการอ่านเป้าหมายและมีการเขียนเพียง 3% เท่านั้นในการดำเนินการเขียน


1

สิ่งนี้ทำให้ฉันสับสนและฉันไม่รู้วิธีเจาะลึกลงไปในสิ่งที่ ZFS กำลังทำอยู่

ฉันกำลังใช้การติดตั้ง FreeNAS 11.1 ใหม่พร้อมกับพูล ZFS ที่รวดเร็ว (มิเรอร์ที่นำเข้าใน 7200s เร็ว) พร้อม UFS SSD เดี่ยวสำหรับการทดสอบ การกำหนดค่าค่อนข้าง "ออกนอกกรอบ"

SSD มี 4 ไฟล์ขนาด 16 -120 GB คัดลอกโดยใช้คอนโซลลงในพูล พูลมีการซ้ำซ้อน (คุ้มค่า: ประหยัด 4x, ขนาด 12TB บนดิสก์) และระบบมี RAM (128GB ECC) และ Xeon ที่รวดเร็ว หน่วยความจำมีเพียงพอ - zdb แสดงให้เห็นว่ากลุ่มมีทั้งหมด 121M บล็อก (544 ไบต์ในแต่ละดิสก์ 175 ไบต์ใน RAM) ดังนั้น DDT ทั้งหมดเป็นเพียงประมาณ 20.3 GB (ประมาณ 1.7 GB ต่อ TB ของข้อมูล)

แต่เมื่อฉันคัดลอกไฟล์ลงในพูลฉันเห็นสิ่งนี้ใน zpool iostat: enter image description here

มันทำรอบของการอ่านมากในระดับต่ำสุดเพียงไม่กี่นาทีและการเขียนสั้น ๆ ส่วนที่อ่านจะแสดงในรูป ความเร็วในการเขียนโดยรวมสำหรับงานนั้นไม่ดีนัก - สระว่ายน้ำว่างเปล่า 45% / 10TB และสามารถเขียนได้ประมาณ 300 - 500 MB / s

ความสงสัยของฉันคือการอ่านระดับต่ำมาจากการอ่าน DDT และข้อมูลเมตาอื่น ๆ เนื่องจากไม่ได้โหลดไว้ใน ARC (หรือถูกผลักออกจาก ARC อย่างต่อเนื่องโดยการเขียนข้อมูลไฟล์) อาจจะ.

อาจเป็นเพราะการค้นหาข้อมูลซ้ำซ้อนจึงมีการเขียนไม่มากนักฉันไม่จำรุ่นที่ซ้ำกันของไฟล์เหล่านี้และมันก็เหมือนกันจาก / dev / random เท่าที่ฉันจำได้ อาจจะ. ไม่มีความคิดที่แท้จริง

ฉันจะทำอย่างไรเพื่อขุดสิ่งที่เกิดขึ้นให้มากขึ้นด้วยมุมมองในการปรับให้เหมาะสม

อัปเดตบน RAM และการลบข้อมูลซ้ำ:

ฉันได้อัปเดต Q เพื่อแสดงขนาด DDT ตามความคิดเห็นเริ่มต้น Dedup RAM มักถูกอ้างอิงเป็น 5GB ต่อ TB x 4 แต่ขึ้นอยู่กับตัวอย่างที่ไม่เหมาะสำหรับการลดความซ้ำซ้อน คุณต้องคำนวณจำนวนบล็อกที่คูณด้วยไบต์ต่อรายการ "x 4" มักจะยกมาเป็นเพียงข้อ จำกัด เริ่มต้น "อ่อน" เท่านั้น (โดยค่าเริ่มต้น ZFS จำกัด ข้อมูลเมตาถึง 25% ของ ARC เว้นแต่ว่าจะบอกให้ใช้มากขึ้น - ระบบนี้มีการระบุไว้สำหรับ dedup และฉันเพิ่ม 64GB ซึ่งเป็น ทั้งหมด สามารถใช้เพื่อเพิ่มความเร็วในการแคชข้อมูลเมตา)

ดังนั้นในสระนี้ zdb ยืนยันว่า DDT ทั้งหมดต้องใช้เพียง 1.7 GB ต่อ TB ไม่ใช่ 5GB ต่อ TB (รวม 20G) และฉันยินดีที่จะให้ข้อมูลเมตา 70% ของ ARC ไม่ใช่ 25% (80G จาก 123G)

ด้วยขนาดดังกล่าวไม่จำเป็นต้องนำออก สิ่งใด นอกเหนือจากเนื้อหาไฟล์ 'dead' จาก ARC ดังนั้นฉันจึงต้องการตรวจสอบ ZFS เพื่อค้นหาสิ่งที่คิดว่าเกิดขึ้นและเพื่อให้ฉันสามารถเห็นผลของการเปลี่ยนแปลงใด ๆ ที่ฉันทำเพราะฉันประหลาดใจจริง ๆ กับจำนวน "ระดับต่ำ" ที่อ่านได้มากและมองหา วิธีตรวจสอบและยืนยันความเป็นจริงของสิ่งที่คิดทำ


มันซ้ำซ้อน จากกฎของหัวแม่มือในบทความ ZFS: เพื่อ Dedupe หรือไม่เพื่อ Dedupe ... คุณอาจต้องการ RAM 240GiB (12TiB × 5GiB / TiB × 4) บางส่วนเพื่อให้พอดีกับตาราง dedup ทั้งหมดในนั้น บทความนั้นอาจมีประโยชน์มากกว่าคำตอบที่ฉันสามารถเขียนได้ที่นี่
Deltik

ขอบคุณและปรับปรุง Q ฉันกำลังมองหาวิธีในการสอบสวนมันมากขึ้น ฉันก็ไม่สามารถคิดว่ามันจะเป็นอะไรได้นอกจากจะไม่เป็นเช่นนั้น ตาราง dedup ในตัวอย่างออนไลน์มาจากกลุ่มที่ไม่มีการทำซ้ำมาก Mine มี 4x และนั่นหมายความว่า DDT ทั้งหมดมีเพียง 1.7GB ต่อ TB หรือ 20GB ต่ำกว่า 17% ของ ARC (ดูการอัปเดตสำหรับการคำนวณ) ในทางทฤษฎีฉันไม่มีที่ใกล้ขีด จำกัด และการหักเงินใด ๆ ที่ควรจะเป็น 100% ใน RAM (หรือปรับได้) ดังนั้นความฉงนสนเท่ห์ของฉันที่กิจกรรมและความสนใจในการพิสูจน์ ZFS เพื่อเรียนรู้สิ่งที่แน่นอน มัน คิดว่ามันกำลังทำจริง .......
Stilez

วิธีการทดสอบข้อมูลเดียวกันภายในกลุ่มใหม่โดยไม่หักเงินซ้ำซ้อน จากนั้นหลังจากนั้นข้อมูลจำนวนน้อยที่มีการหักข้อมูล แต่ตามกฎ Deltik ที่โพสต์ ด้วยวิธีนี้คุณสามารถลดปัจจัยที่ไม่ทราบได้อย่างรวดเร็ว
user121391
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.