ZFS pool อ่านต่อเนื่องช้า

ฉันมีคำถามที่เกี่ยวข้องกับปัญหานี้ แต่มันซับซ้อนเกินไปและใหญ่เกินไปดังนั้นฉันตัดสินใจว่าฉันควรแยกปัญหาออกเป็น NFS และปัญหาในท้องถิ่น ฉันได้ลองถามเกี่ยวกับเรื่องนี้ในรายชื่อผู้รับจดหมาย zfs-discuss ไม่สำเร็จมาก

การคัดลอกช้าระหว่างไดเร็กทอรี NFS / CIFS บนเซิร์ฟเวอร์เดียวกัน

โครงร่าง: ฉันติดตั้งอย่างไรและสิ่งที่ฉันคาดหวัง

1. ฉันมีพูล ZFS พร้อมดิสก์ 4 ตัว 2TB RED กำหนดค่าเป็น 2 มิเรอร์ที่มีลาย (RAID 10) บน Linux, zfsonlinux ไม่มีแคชหรืออุปกรณ์บันทึก
2. ข้อมูลมีความสมดุลระหว่างกระจก (สำคัญสำหรับ ZFS)
3. แต่ละดิสก์สามารถอ่าน (raw w / dd) ที่ 147MB / วินาทีในแบบคู่ขนานให้ปริมาณงานรวม 588MB / วินาที
4. ฉันคาดหวังว่าจะมีการเขียน 115MB / วินาที, อ่านได้ 138MB / วินาทีและเขียนข้อมูลแบบลำดับต่อเนื่องจากแต่ละดิสก์ 50MB / วินาทีตามเกณฑ์มาตรฐานของดิสก์ 4TB RED ที่คล้ายคลึงกัน ฉันคาดว่าจะอ่านหรือเขียนไม่น้อยกว่า 100MB / วินาทีเนื่องจากดิสก์ใด ๆ สามารถทำได้ในทุกวันนี้
5. ฉันคิดว่าฉันจะเห็นการใช้ประโยชน์ IO 100% ในดิสก์ทั้ง 4 เมื่ออ่านโหลดหรือเขียนข้อมูลตามลำดับ และที่ดิสก์จะวางมากกว่า 100MB / วินาทีในขณะที่การใช้งาน 100%
6. ฉันคิดว่าสระว่ายน้ำจะให้ฉันประมาณ 2x เขียนเขียน 2x และประสิทธิภาพการอ่าน 4x บนดิสก์เดียว - ฉันผิดหรือเปล่า?
7. ใหม่ฉันคิดว่า ext4 zvol ในกลุ่มเดียวกันจะมีความเร็วเท่ากับ ZFS

สิ่งที่ฉันได้รับจริง

ฉันพบว่าประสิทธิภาพการอ่านของพูลไม่สูงเกือบเท่าที่ฉันคาดไว้

เกณฑ์มาตรฐานบอนนี่ ++บนสระว่ายน้ำจากไม่กี่วันที่ผ่านมา

รุ่น 1.97 ------ การส่งออกต่อเนื่อง ------ - ลำดับอินพุต - - สุ่ม -
การเกิดขึ้นพร้อมกัน 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
ขนาดเครื่องจักร K / วินาที% CP K / วินาที% CP K / วินาที% CP K / วินาที% CP K / วินาที% CP / วินาที% CP
igor 63G 99 99 232132 47 118787 27 336 97 257072 22 92.7 6

bonnie ++บนไดรฟ์สีแดงขนาด 4TB ตัวเดียวบน zpool

รุ่น 1.97 ------ การส่งออกต่อเนื่อง ------ - ลำดับอินพุต - - สุ่ม -
การเกิดขึ้นพร้อมกัน 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
ขนาดเครื่องจักร K / วินาที% CP K / วินาที% CP K / วินาที% CP K / วินาที% CP K / วินาที% CP / วินาที% CP
igor 63G 101 99 115288 30 49781 14 326 97 138250 13 111.6 8

ด้วยเหตุนี้ความเร็วในการอ่านและเขียนใหม่จึงเหมาะสมตามผลลัพธ์จากไดรฟ์ 4TB RED เดียว (เป็นสองเท่า) อย่างไรก็ตามความเร็วในการอ่านที่ฉันคาดว่าน่าจะอยู่ที่ประมาณ 550MB / วินาที (ความเร็ว 4 เท่าของไดรฟ์ 4TB) และอย่างน้อยฉันก็หวังว่าจะอยู่ที่ประมาณ 400MB / วินาที แต่ฉันเห็นประมาณ 260MB / วินาที

bonnie ++บนสระว่ายน้ำจากตอนนี้ในขณะที่รวบรวมข้อมูลด้านล่าง ไม่เหมือนเมื่อก่อนและไม่มีอะไรเปลี่ยนแปลง

รุ่น 1.97 ------ การส่งออกต่อเนื่อง ------ - ลำดับอินพุต - - สุ่ม -
การเกิดขึ้นพร้อมกัน 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seek--
ขนาดเครื่องจักร K / วินาที% CP K / วินาที% CP K / วินาที% CP K / วินาที% CP K / วินาที% CP / วินาที% CP
igor 63G 103 99 207518 43 108810 24 342 98 302350 26 256.4 18

zpool iostatระหว่างการเขียน ดูเหมือนว่าตกลงกับฉัน

                                                 แบนด์วิดธ์การดำเนินงานความจุ
พูลจัดสรรฟรีอ่านเขียนเขียนอ่าน
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.23T 2.39T 0 1.89K 1.60K 238M
  กระจก 631G 1.20T 0 979 1.60K 120M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 0 1007 1.60K 124M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 0 975 0 120M
  กระจก 631G 1.20T 0 953 0 117M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 0 1.01K 0 128M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 0 953 0 117M

zpool iostatระหว่างเขียนใหม่ ดูเหมือนว่าตกลงที่จะฉันฉันคิดว่า

                                                 แบนด์วิดธ์การดำเนินงานความจุ
พูลจัดสรรฟรีอ่านเขียนเขียนอ่าน
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 1015 923 125M 101M
  กระจก 651G 1.18T 505 465 62.2M 51.8M
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 198 438 24.4M 51.7M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 306 384 37.8M 45.1M
  กระจก 651G 1.18T 510 457 63.2M 49.6M
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 304 371 37.8M 43.3M
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 206 423 25.5M 49.6M

นี่คือที่ฉันสงสัยว่าเกิดอะไรขึ้น

zpool iostatระหว่างอ่าน

                                                 แบนด์วิดธ์การดำเนินงานความจุ
พูลจัดสรรฟรีอ่านเขียนเขียนอ่าน
-------------------------------------------- ----- - ---- ----- ----- ----- -----
pool2 1.27T 2.35T 2.68K 32 339M 141K
  กระจก 651G 1.18T 1.34K 20 169M 90.0K
    ata-WDC_WD20EFRX-68AX9N0_WD-WMC300004469 - - 748 9 92.5M 96.8K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4MLK57MVX - - 623 10 76.8M 96.8K
  กระจก 651G 1.18T 1.34K 11 170M 50.8K
    ata-WDC_WD20EFRX-68AX9N0_WD-WCC1T0429536 - - 774 5 95.7M 56.0K
    ata-WDC_WD20EFRX-68EUZN0_WD-WCC4M0VYKFCE - - 599 6 74.0M 56.0K

iostat -xระหว่างการดำเนินการอ่านเดียวกัน สังเกตว่า IO% ไม่ได้อยู่ที่ 100%

อุปกรณ์: rrqm / s wrqm / sr / sw / s rkB / s wkB / s avgrq-sz avgqu-sz กำลังรอ r_await w_await svctm% util
sdb 0.60 0.00 661.30 6.00 83652.80 49.20 250.87 2.32 3.47 3.46 4.87 1.20 79.76
sdd 0.80 0.00 735.40 5.30 93273.20 49.20 251.98 2.60 3.51 3.51 4.15 1.20 89.04
sdf 0.50 0.00 656.70 3.80 83196.80 31.20 252.02 2.23 3.38 3.36 6.63 1.17 77.12
sda 0.70 0.00 738.30 3.30 93572.00 31.20 252.44 2.45 3.33 3.31 7.03 1.14 84.24

zpool และการตั้งค่าชุดข้อมูลทดสอบ:

• เวลาปิด
• การบีบอัดปิด
• Ashift เป็น 0 (ตรวจสอบอัตโนมัติ - ความเข้าใจของฉันคือว่านี่ก็โอเค)
• zdb กล่าวว่าดิสก์มีทั้งหมด ashift = 12
• โมดูล - ตัวเลือก zfs zvol_threads = 32 zfs_arc_max = 17179869184
• sync = standard

แก้ไข - 30 ต.ค. 2558

ฉันทำการทดสอบเพิ่มเติม

• ชุดข้อมูล bonnie ++ w / recordsize = 1M = 226MB เขียน 392MB อ่านดีขึ้นมาก
• ชุดข้อมูล dd w / ขนาดบันทึก = 1M = เขียน 260MB, 392MB อ่านดีขึ้นมาก
• zvol w / ext4 dd bs = 1M = 128MB เขียน, 107MB อ่านทำไมช้าจัง?
• ชุดข้อมูล 2 processess ในแบบขนาน = 227MB write, 396MB read
• dd direct io ไม่ได้ทำให้ชุดข้อมูลและ zvol แตกต่างกัน

ฉันมีความสุขมากกับการแสดงที่เพิ่มขนาดบันทึก ไฟล์ในพูลเกือบทุกไฟล์มีขนาดเกิน 1MB ดังนั้นฉันจะปล่อยให้มันเป็นอย่างนั้น ดิสก์ยังไม่ได้รับการใช้งาน 100% ซึ่งทำให้ฉันสงสัยว่ามันจะยังเร็วกว่านี้หรือไม่ และตอนนี้ฉันสงสัยว่าทำไมประสิทธิภาพของ zvol จึงเป็นเรื่องที่น่ารังเกียจเพราะนั่นเป็นสิ่งที่ฉันใช้ (เบา ๆ )

ฉันยินดีที่จะให้ข้อมูลใด ๆ ที่ร้องขอในความคิดเห็น / คำตอบ นอกจากนี้ยังมีข้อมูลมากมายที่โพสต์ในคำถามอื่น ๆ ของฉัน: การคัดลอกช้าระหว่างไดเรกทอรี NFS / CIFS บนเซิร์ฟเวอร์เดียวกัน

ฉันตระหนักดีว่าฉันอาจไม่เข้าใจบางสิ่งบางอย่างและสิ่งนี้อาจไม่เป็นปัญหาเลย ขอบคุณล่วงหน้า.

เพื่อให้ชัดเจนคำถามคือ: ทำไม ZFS pool ไม่เร็วอย่างที่ฉันคาดไว้ และอาจจะมีอะไรผิดปกติอีกไหม?

ฉันจัดการเพื่อให้ได้ความเร็วใกล้เคียงกับตัวเลขที่ฉันคาดหวังมาก

ผมกำลังมองหา400MB / วินาทีและมีการจัดการ392MB / วินาที ดังนั้นฉันพูดได้ว่าปัญหาได้รับการแก้ไข ด้วยการเพิ่มอุปกรณ์แคชในภายหลังฉันจัดการอ่าน458MB / วินาที (ฉันเชื่อว่าแคช)

1.สิ่งนี้ในตอนแรกทำได้โดยการเพิ่มrecordsizeค่าชุดข้อมูล ZFS เป็น1M

zfs set recordsize=1M pool2/test

ฉันเชื่อว่าการเปลี่ยนแปลงนี้ส่งผลให้กิจกรรมของดิสก์น้อยลงดังนั้นการอ่านและเขียนข้อมูลขนาดใหญ่ที่มีประสิทธิภาพยิ่งขึ้น สิ่งที่ฉันขอ

ผลลัพธ์หลังจากการเปลี่ยนแปลง

• bonnie ++ = 226MB เขียน, 392MB อ่าน
• dd = 260MB write, 392MB read
• 2 กระบวนการแบบขนาน = 227MB เขียน 396MB อ่าน

2.ฉันจัดการได้ดียิ่งขึ้นเมื่อฉันเพิ่มอุปกรณ์แคช (120GB SSD) การเขียนช้าลงฉันไม่แน่ใจว่าทำไม

Version  1.97       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
igor            63G           208325  48 129343  28           458513  35 326.8  16

เคล็ดลับกับอุปกรณ์แคชคือการตั้งค่าl2arc_noprefetch=0ใน/etc/modprobe.d/zfs.conf อนุญาตให้ ZFS แคชการสตรีม / ข้อมูลต่อเนื่อง ทำเช่นนี้เฉพาะเมื่ออุปกรณ์แคชของคุณเร็วกว่าอาเรย์ของคุณเช่นเดียวกับฉัน

หลังจากได้รับประโยชน์จากการเปลี่ยนแปลงบันทึกชุดข้อมูลของฉันฉันคิดว่ามันอาจเป็นวิธีที่คล้ายกันในการจัดการกับประสิทธิภาพการทำงานที่ไม่ดีของ zvol

ฉันเจอคนที่แยกตัวกันพูดถึงว่าพวกเขาได้รับประสิทธิภาพที่ดีเมื่อใช้ a volblocksize=64kดังนั้นฉันจึงลอง ไม่มีโชค.

zfs create -b 64k -V 120G pool/volume

แต่แล้วผมอ่านที่ ext4 (ระบบแฟ้มฉันถูกทดสอบด้วย) ตัวเลือกการสนับสนุนสำหรับ RAID เหมือนstrideและstripe-widthซึ่งผมไม่เคยใช้มาก่อน ดังนั้นฉันใช้เว็บไซต์นี้เพื่อคำนวณการตั้งค่าที่ต้องการ: https://busybox.net/~aldot/mkfs_stride.htmlและจัดรูปแบบ zvol อีกครั้ง

mkfs.ext3 -b 4096 -E stride=16,stripe-width=32 /dev/zvol/pool/volume

ฉันวิ่งbonnie++ไปทำเกณฑ์มาตรฐานอย่างง่ายและผลลัพธ์ก็ยอดเยี่ยม ฉันไม่ได้ผลลัพธ์กับฉัน แต่น่าเสียดายที่พวกเขาเขียนได้เร็วกว่า 5-6x อย่างน้อยขณะที่ฉันจำได้ ฉันจะอัปเดตคำตอบนี้อีกครั้งถ้าฉันเปรียบเทียบอีกครั้ง

ผลลัพธ์ของคุณมีความสมเหตุสมผลอย่างสมบูรณ์แบบในขณะที่ความคาดหวังของคุณไม่ใช่: คุณพูดเกินจริงในการปรับปรุงประสิทธิภาพการอ่านที่ได้รับจาก RAID1 (และโดยการขยายโดย RAID10) ประเด็นก็คือการทำมิเรอร์แบบ 2 ทางให้ความเร็วในการอ่าน / IOP สูงสุด 2 เท่าของดิสก์แผ่นเดียว แต่ประสิทธิภาพในโลกแห่งความเป็นจริงสามารถอยู่ที่ใดก็ได้ระหว่าง 1x-2x

ขอชี้แจงด้วยตัวอย่าง ลองนึกภาพว่าจะมีระบบที่มีมิเรอร์ 2 ทิศทางโดยแต่ละดิสก์สามารถใช้ 100 MB / s (เรียงตามลำดับ) และ 200 IOPS ด้วยความลึกของคิวที่ 1 (สูงสุดหนึ่งคำขอที่ค้าง) อาร์เรย์นี้จะไม่มีข้อได้เปรียบกว่าดิสก์เดียว: RAID1 แยกคำขอ IO บนคิวของดิสก์สองตัว แต่ไม่แยกคำขอเดี่ยวมากกว่าสองดิสก์ (อย่างน้อย การนำไปปฏิบัติใด ๆ ที่ฉันเห็นมีพฤติกรรมในลักษณะนี้) ในอีกด้านหนึ่งถ้าคิว IO ของคุณใหญ่กว่า (เช่น: คุณมีคำขอค้าง 4/8) ปริมาณงานดิสก์ทั้งหมดจะสูงกว่าดิสก์เดียวอย่างมาก

จุดที่คล้ายกันสามารถทำได้สำหรับ RAID0 แต่ในกรณีนี้สิ่งที่กำหนดปรับปรุงเฉลี่ยคือฟังก์ชั่นไม่เพียง แต่ขนาดคิว แต่ขนาดคำขอ IO ยัง : ถ้าขนาด IO เฉลี่ยของคุณต่ำกว่าขนาดก้อนแล้วมันจะไม่ถูกสไทรพ์ บนดิสก์สองแผ่น (หรือมากกว่า) แต่จะให้บริการโดยดิสก์เดี่ยว ผลลัพธ์ของคุณด้วยการเพิ่มขนาดระเบียน Bonnie ++ แสดงพฤติกรรมที่แน่นอนนี้: การสไทรพ์ได้รับประโยชน์อย่างมากจากขนาด IO ที่ใหญ่กว่า

ตอนนี้ควรชัดเจนว่าการรวมสองระดับ RAID ในอาเรย์ RAID10 จะไม่นำไปสู่การเพิ่มประสิทธิภาพเชิงเส้น แต่จะตั้งค่าขีด จำกัด สูงสุดสำหรับมัน ฉันค่อนข้างแน่ใจว่าถ้าคุณเรียกใช้อินสแตนซ์ dd / bonnie ++ หลาย ๆ ตัว (หรือใช้fioเพื่อจัดการคิว IO โดยตรง) คุณจะได้ผลลัพธ์ที่ตรงกับความคาดหวังดั้งเดิมของคุณมากขึ้นเพียงเพราะคุณจะเก็บภาษีอาร์เรย์ IO ของคุณในลักษณะที่สมบูรณ์มากขึ้น การร้องขอตามลำดับ / สุ่ม IO หลายอย่างต่อเนื่อง) แทนที่จะโหลดแบบคำร้องขอ IO ลำดับต่อเนื่องเดียว