ปรับแต่งการขัด ZFS, 141KB / s ทำงานเป็นเวลา 15 วัน

ระบบพื้นฐานที่ใช้งาน Mirror + Stripe บนระบบดิสก์ sas ขนาด 7.2k รอบต่อนาทีไม่โหลดเป็นพิเศษ ไม่มีการลดการซ้ำซ้อนการบีบอัดบนชุดข้อมูลทั้งหมด สครับทำงานเป็นเวลา 15 วันด้วยความเร็วของหอยทากที่ตายแล้ว มีการเพิ่มประสิทธิภาพบางอย่างที่ต้องทำหรืออาจเป็นเพราะความผิดพลาดบางอย่าง?

• Dell R510 พร้อมตัวเครื่อง MD1200
• 2x Xeon E5620
• 48GB
• NexentaStor 3.1.3 รุ่นชุมชน

ข้อมูลบางอย่าง:

scan: scrub in progress since Mon Apr  1 19:00:05 2013
171G scanned out of 747G at 141K/s, 1187h40m to go
0 repaired, 22.84% done
config:

    NAME                       STATE     READ WRITE CKSUM
    tank                       ONLINE       0     0     0
      mirror-0                 ONLINE       0     0     0
        c7t5000C500414FB2CFd0  ONLINE       0     0     0
        c7t5000C500414FCA57d0  ONLINE       0     0     0
      mirror-1                 ONLINE       0     0     0
        c7t5000C500415C3B1Bd0  ONLINE       0     0     0
        c7t5000C500415C5E4Fd0  ONLINE       0     0     0
      mirror-2                 ONLINE       0     0     0
        c7t5000C500415DC797d0  ONLINE       0     0     0
        c7t5000C500415DC933d0  ONLINE       0     0     0
    logs
      c7t5000A7203006D81Ed0    ONLINE       0     0     0
    cache
      c7t5000A72030068545d0    ONLINE       0     0     0


# iostat -en     
---- errors --- 
s/w h/w trn tot device
0 8887   0 8887 c2t0d0
0   0   0   0 c0t395301D6B0C8069Ad0
0   0   0   0 c7t5000C500415DC933d0
0   0   0   0 c7t5000A72030068545d0
0   0   0   0 c7t5000C500415DC797d0
0   0   0   0 c7t5000C500414FCA57d0
0   0   0   0 c7t5000C500415C3B1Bd0
0   0   0   0 c7t5000C500415C5E4Fd0
0   0   0   0 c7t5000C500414FB2CFd0
0   0   0   0 c7t5000A7203006D81Ed0

spa_last_io มีการเปลี่ยนแปลงทุกครั้งที่ฉันเรียกใช้

# echo "::walk spa | ::print spa_t spa_name spa_last_io spa_scrub_inflight" | mdb -k
spa_name = [ "syspool" ]
spa_last_io = 0x25661402
spa_scrub_inflight = 0
spa_name = [ "tank" ]
spa_last_io = 0x25661f84
spa_scrub_inflight = 0x21

ทุก 5 วินาทีเขียนประมาณ 20-25 MB / s ระหว่างการเขียนนั้นไม่มีการอ่านหรือเขียน

                          capacity     operations    bandwidth      latency
    pool                       alloc   free   read  write   read  write   read  write
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    syspool                     427G   501G      0      0      0      0   0.00   0.00
      c0t395301D6B0C8069Ad0s0   427G   501G      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----
    tank                        903G  1.84T    810  5.21K  1.50M  20.8M   9.42   4.71
      mirror                    301G   627G     22  1.00K  53.0K  3.96M   8.96   3.93
        c7t5000C500414FB2CFd0      -      -     20    244  50.1K  3.97M   6.70   1.14
        c7t5000C500414FCA57d0      -      -     19    242  48.2K  3.97M   7.60   1.12
      mirror                    301G   627G     25   1016  46.8K  4.10M  16.11   5.28
        c7t5000C500415C3B1Bd0      -      -     21    257  41.6K  4.11M   4.63   1.24
        c7t5000C500415C5E4Fd0      -      -     21    255  43.0K  4.11M  16.54   1.15
      mirror                    301G   627G     62    754   119K  3.03M  19.72   3.78
        c7t5000C500415DC797d0      -      -     57    219   114K  3.03M   9.99   1.15
        c7t5000C500415DC933d0      -      -     56    220   119K  3.03M  13.20   1.22
      c7t5000A7203006D81Ed0     260K  46.5G      0      0      0      0   0.00   0.00
    cache                          -      -      -      -      -      -
      c7t5000A72030068545d0    93.1G     8M      0      0      0      0   0.00   0.00
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

iostats กำลังบอกฉันว่าฉันใช้เวลามากขึ้นในการรอแผ่นดิสก์จากนั้นฉันควรจะต้องทำหรือไม่? โดยเฉพาะคอลัมน์% b

# iostat -xe
device    r/s    w/s   kr/s   kw/s wait actv  svc_t  %w  %b s/w h/w trn tot 
sd3       5.1   43.9   20.6  643.8  0.0  0.1    2.9   0   5   0   0   0   0 
sd4       9.4    1.8  141.1  169.6  0.0  0.0    0.5   0   0   0   0   0   0 
sd5       3.1   43.8   15.8  643.8  0.0  0.1    1.4   0   3   0   0   0   0 
sd6       5.2   38.1   14.3  494.4  0.0  0.1    3.0   0   7   0   0   0   0 
sd7       4.2   40.2   11.1  623.2  0.0  0.1    2.7   0   7   0   0   0   0 
sd8       3.6   44.3    9.7  623.2  0.0  0.1    1.5   0   4   0   0   0   0 
sd9       2.9   37.4    7.0  494.4  0.0  0.1    1.3   0   2   0   0   0   0 
sd10      0.7    0.4    3.4    0.0  0.0  0.0    0.0   0   0   0   0   0   0 

ความหน่วงแฝงอยู่ที่ด้านสูง?

# zpool iostat 10 10
               capacity     operations    bandwidth      latency
pool        alloc   free   read  write   read  write   read  write
tank         909G  1.83T     86  2.82K   208K  12.7M  22.68  13.63
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     29    857  42.4K  3.50M  17.86   4.47
----------  -----  -----  -----  -----  -----  -----  -----  -----
tank         909G  1.83T     30    947  46.1K  3.54M  15.55   5.67

ใช้การปรับแต่งเล็กน้อยซึ่งสร้างความแตกต่างเล็กน้อย zfs_top_maxinflight ตั้งค่าเป็น 127, zfs_scrub_delay เป็น 0 และ zfs_scan_idle เป็น 0

# echo zfs_top_maxinflight | mdb -k
zfs_top_maxinflight:
zfs_top_maxinflight:            127

# echo zfs_scrub_delay/D |mdb -k
zfs_scrub_delay:
zfs_scrub_delay:0

# echo zfs_scan_idle/D |mdb -k
zfs_scan_idle:
zfs_scan_idle:  0


 scan: scrub in progress since Wed Apr 17 20:47:23 2013
    1.85G scanned out of 918G at 1.14M/s, 229h36m to go
    0 repaired, 0.20% done

ก่อนหน้านี้ปรับแต่งสังเกตเห็นคอลัมน์ b% ค่อนข้างสูง

$ iostat -nx -M 5

  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c0t395301D6B0C8069Ad0
 35.2   44.2    0.3    0.7  0.0  0.4    0.0    5.3   0  32 c7t5000C500415DC933d0
 19.8    3.2    0.2    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A72030068545d0
 31.2   46.2    0.2    0.7  0.0  0.3    0.0    4.4   0  27 c7t5000C500415DC797d0
 30.6   46.8    0.2    0.8  0.0  0.4    0.0    4.6   0  28 c7t5000C500414FCA57d0
 37.6   53.0    0.3    0.8  0.0  0.4    0.0    4.7   0  33 c7t5000C500415C3B1Bd0
 37.6   53.6    0.3    0.8  0.0  0.5    0.0    5.6   0  39 c7t5000C500415C5E4Fd0
 33.2   46.8    0.3    0.8  0.0  0.5    0.0    6.1   0  33 c7t5000C500414FB2CFd0
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c7t5000A7203006D81Ed0

โพสต์ mdb ปรับแต่งสังเกตเห็นคอลัมน์ b% เวลา 80-85% ในการรอไม่ว่าง

$ iostat -nx -M 5 
  r/s    w/s   Mr/s   Mw/s wait actv wsvc_t asvc_t  %w  %b device
  0.0    0.0    0.0    0.0  0.0  0.0    0.0    0.0   0   0 c2t0d0
  0.2   27.2    0.0    0.3  0.0  1.0    0.0   35.4   0  18 c0t395301D6B0C8069Ad0
129.6   20.2    0.9    0.4  0.0  2.9    0.0   19.5   0  85 c7t5000C500415DC933d0
 48.4    4.0    0.4    0.0  0.0  0.0    0.0    0.1   0   1 c7t5000A72030068545d0
130.4   19.8    0.9    0.4  0.0  3.0    0.0   20.2   0  84 c7t5000C500415DC797d0
125.8   25.8    0.9    0.5  0.0  2.9    0.0   19.2   0  80 c7t5000C500414FCA57d0
131.2   24.2    0.9    0.5  0.0  3.1    0.0   20.3   0  83 c7t5000C500415C3B1Bd0
130.6   25.8    0.9    0.5  0.0  3.5    0.0   22.5   0  88 c7t5000C500415C5E4Fd0
126.8   28.0    0.9    0.5  0.0  2.8    0.0   18.0   0  79 c7t5000C500414FB2CFd0
  0.2    0.0    0.0    0.0  0.0  0.0    0.0    0.1   0   0 c7t5000A7203006D81Ed0

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

ปรับได้เพื่อสำรวจพร้อมกับบันทึกย่อของฉันเกี่ยวกับสิ่งที่มันทำ (ฉันดูครั้งสุดท้ายในชั่วขณะนี้ที่ผ่านมาแม้ว่า):

• zfs_scan_idle - หาก I / O ของผู้ใช้เกิดขึ้นภายในนาฬิกาติ๊กนี้ล่าช้า I / O ขัดโดย zfs_scrub_delay เห็บนาฬิกา
• zfs_scrub_delay - มีจำนวนนาฬิกากี่เห็บที่จะชะลอการขัดถูหากถูกเรียกใช้โดย zfs_scan_idle
• zfs_top_maxinflight - จำนวน I / O สูงสุดของการขัดต่อ vdev ระดับสูงสุด
• zfs_scrub_limit - จำนวน I / O สูงสุดของการขัดต่อ leaf vdev
• zfs_scan_min_time_ms - ms ขั้นต่ำที่จะใช้ต่อ txg ในการขัดผิวหน้า
• zfs_no_scrub_io - ไม่มีโน้ต
• zfs_no_scrub_prefetch - ไม่มีโน้ตชื่อดูเหมือนจะบอกเป็นนัย ๆ ว่าไม่ได้ก่อให้เกิดการดึง prefetch บน ops ขัด

สิ่งเหล่านี้สามารถเปลี่ยนแปลงได้ทันทีโดยใช้ "echo [tunable] / W0t [number]" เพื่อเปลี่ยนและ "echo [tunable] / D" เพื่อดูการตั้งค่าปัจจุบัน (ซึ่งฉันแนะนำให้ทำก่อนที่จะเปลี่ยน)

ดังนั้นในทางทฤษฎีและโดยทั่วไปถ้าคุณพูดเปลี่ยน zfs_scan_idle ลงไปที่ 10 (หรือ 1 - หรือ 0 หากสนับสนุนนั้นจะต้องตรวจสอบรหัส) และ zfs_scrub_delay ลง 1 (หรือ 0 ถ้า มันสนับสนุนสิ่งนั้น) และหากการตั้งค่า txg_synctime_ms ของคุณเป็น 5,000 หรือมากกว่านั้นอาจเปลี่ยน zfs_scan_min_time_ms ขึ้นมาสักหน่อยมันควรจะเป็นเชิงรุกมากขึ้นเกี่ยวกับการขัดผิวจริง ๆ แม้ว่าจะมี I / O ผู้ใช้ในระดับหนึ่งเกิดขึ้น

ในกรณีเฉพาะของคุณ% b และ asvc_t รายงานว่าปริมาณงานอ่านที่สุ่มมากเกิดขึ้น (ดิสก์หมุนควรทำดีกว่านั้นถ้าเป็นลำดับอย่างแท้จริง) และคุณได้ทำสิ่ง "ง่าย" ตามที่อธิบายไว้ข้างต้น . ดังนั้นก่อนอื่นฉันจะเปิด zfs_no_scrub_prefetch เพื่อปิดใช้งานการดึงข้อมูลล่วงหน้าในการดำเนินการขัดเพียงเพื่อดูว่าช่วยได้หรือไม่ หากไม่มีความสุขขึ้นอยู่กับรุ่นของ Nexenta ที่คุณเปิด - คุณอาจเรียกใช้ 30/5, 5/1 หรือ 10/5 (นั่นคือสิ่งที่เราใช้สำหรับการตั้งค่าของ zfs_txg_timeout & (zfs_txg_synctime_ms * 1000) เปลี่ยน zfs_txg_timeout เป็น 10 และ zfs_txg_synctime_ms เป็น 5,000 จากนั้นลองเพิ่ม zfs_scan_min_time_ms เป็น 3000 หรือ 4000 สิ่งนี้บอก ZFS ว่าสามารถใช้เวลานานในการขัดมากกว่าเมื่อเทียบกับการตั้งค่าเริ่มต้นบน NexentaStor ที่เก่ากว่า ระวัง

หวังว่านี่จะช่วยได้ โชคดี!

ฉันสงสัยว่าฮาร์ดแวร์ ...

ทำไมคุณต้องปล่อยให้เรื่องนี้เป็นเวลา 15 วัน? นั่นไม่ใช่เรื่องปกติ หยุดขัด - zpool scrub -s tankและตรวจสอบระบบออก

• คุณใช้คอนโทรลเลอร์รุ่นใด
• นี่เป็นสครัปแรกที่คุณเคยใช้ในสระนี้หรือไม่?
• มีปัญหาอะไรที่ทำให้คุณต้องขัดผิวในครั้งแรกหรือไม่?

คำตอบของฉันมาสายนิดหน่อย แต่ถ้าเรื่องแบบนี้เกิดขึ้นกับคนอื่นนี่คือสิ่งที่ฉันจะทำ: ลอง "dmesg" ในกรณีของฉันฉันไม่ได้ทำการขัดตัว แต่ฉันกำลังคัดลอกไฟล์ไปยังดิสก์และฉันได้ยินชัดเจนว่าดิสก์นั้นทำงานอยู่สองสามวินาทีจากนั้นก็หยุดทำงานเป็นเวลานานขึ้นและทำงานอีกครั้ง นี่เป็นเพราะความล้มเหลวของคอนโทรลเลอร์ SATA หนึ่งตัวและ dmesg ทำให้ฉันมีข้อผิดพลาดทั้งหมด ฉันคิดว่ามันเป็นดิสก์ที่ล้มเหลวในตอนแรก แต่แล้วฉันก็รู้ว่ามันเป็นคอนโทรลเลอร์จริงๆ

Scrub ใช้การหยุดทำงานของระบบที่มีอยู่แม้บนเซิร์ฟเวอร์ที่ไม่มีการโหลด Ram และตัวประมวลผลเป็นกุญแจสำคัญในการขัดการใช้งานไม่ใช่แผ่นดิสก์ ยิ่งมีสิ่งเหล่านี้มากเท่าไหร่ประสิทธิภาพการขัดผิวของคุณก็จะยิ่งดีขึ้นเท่านั้น อย่างไรก็ตามในกรณีนี้แผ่นดิสก์ของคุณจะวางได้ดีขึ้นในแง่ของ ZPools ประสิทธิภาพการขัดผิวของคุณก็จะดีขึ้นเช่นกัน

ดังนั้นหากการแสดงของคุณช้าและดูเหมือนว่าเป็นกรณีนี้ฉันจะมองว่าสิ่งเหล่านี้เป็นเหตุผลที่เป็นไปได้