Điều chỉnh quá trình chà ZFS, 141KB / giây chạy trong 15 ngày

Một hệ thống khá cơ bản chạy gương + sọc trên đĩa sas 7.2k vòng / phút, không được tải đặc biệt. Không khấu trừ, nén trên tất cả các bộ dữ liệu. Scrub đã chạy được 15 ngày với tốc độ của một con ốc chết. Có một số tối ưu hóa cần phải được thực hiện, hoặc có thể là do một số hw bị lỗi?

• Dell R510 với vỏ MD1200.
• 2 Xeon E5620
• 48 GB
• NexentaStor 3.1.3, phiên bản cộng đồng

Một số thông tin:

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 được thay đổi mỗi khi tôi chạy cái này

# 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

Cứ sau 5 giây, khoảng 20-25 MB / s được viết. Giữa những bài viết về cơ bản không có đọc hay viết.

                          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
    -------------------------  -----  -----  -----  -----  -----  -----  -----  -----

Có phải các iostats nói với tôi rằng tôi đang dành nhiều thời gian hơn để chờ đĩa thì tôi có nên không? Cụ thể là cột% 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 

Độ trễ một chút ở phía cao?

# 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

Áp dụng một số điều chỉnh mà làm cho sự khác biệt nhỏ. zfs_top_maxinflight được đặt thành 127, zfs_scrub_delay thành 0 và zfs_scan_idle thành 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

chỉnh mdb trước, chú ý cột b% khá cao

$ iter -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

đăng bài chỉnh sửa mdb, chú ý cột b%, thời gian chờ bận rộn 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

Các hoạt động chà ZFS hoạt động trên một số nguyên tắc khá hại não. Đáng chú ý nhất, nó chỉ dành thời gian cọ rửa khi không có gì khác xảy ra. Nếu bạn chọc một nhóm chỉ với một chút quyền truy cập dữ liệu trên cơ sở khá ổn định, chà sẽ tự bỏ đói một cách hiệu quả và gần như không làm gì cả.

Điều chỉnh để khám phá, với những ghi chú nhanh của tôi về những gì nó làm (lần cuối tôi đã xem xét một lúc trước đây):

• zfs_scan_idle - nếu I / O của người dùng xảy ra trong nhiều dấu tích đồng hồ này, hãy trì hoãn xóa I / O bởi zfs_scrub_delay tick
• zfs_scrub_delay - có bao nhiêu tích tắc đồng hồ để trì hoãn hoạt động chà nếu được kích hoạt bởi zfs_scan_idle
• zfs_top_maxinflight - số lượng I / O chà tối đa trên mỗi vdev cấp cao nhất
• zfs_scrub_limit - số lượng I / O chà tối đa trên mỗi lá vdev
• zfs_scan_min_time_ms - tối thiểu ms để chi cho mỗi txg cho các hoạt động chà
• zfs_no_scrub_io - không có ghi chú
• zfs_no_scrub_prefetch - không có ghi chú, tên dường như ngụ ý không gây ra việc tìm nạp trước trên ops ops

Tất cả những thứ này đều có thể thay đổi khi đang sử dụng "echo [tunable] / W0t [number]" để thay đổi và "echo [tunable] / D" để xem cài đặt hiện tại (mà tôi khuyên bạn nên thực hiện trước khi thay đổi).

Vì vậy, về lý thuyết và trong thực tế chung, nếu bạn muốn, thay đổi zfs_scan_idle xuống 10 (hoặc 1 - hoặc 0, nếu nó hỗ trợ điều đó, sẽ cần kiểm tra mã) và zfs_scrub_delay xuống 1 (hoặc 0, nếu nó hỗ trợ điều đó) và nếu cài đặt txg_synctime_ms của bạn từ 5000 trở lên có thể thay đổi zfs_scan_min_time_ms một chút, nó sẽ trở nên tích cực hơn rất nhiều khi thực hiện các thao tác chà ngay cả khi xảy ra một số mức I / O của người dùng.

Trong trường hợp cụ thể của bạn,% b và asvc_t đã báo cáo ngụ ý một số khối lượng công việc đọc rất ngẫu nhiên đang diễn ra (đĩa quay sẽ làm tốt hơn thế nếu nó thực sự tuần tự) và bạn đã thực hiện công cụ "dễ dàng" như đã giải thích ở trên . Vì vậy, trước tiên tôi bật zfs_no_scrub_prefetch, để vô hiệu hóa tính năng tìm nạp trước trên các hoạt động chà, chỉ để xem điều đó có giúp ích không. Nếu không có niềm vui, tùy thuộc vào phiên bản Nexenta bạn đang bật - bạn có thể đang chạy 30/5, 5/1 hoặc 10/5 (đó là cách viết tắt mà chúng tôi sử dụng cho các cài đặt của zfs_txg_timeout & (zfs_txg_synctime_ms * 1000)). Thay đổi zfs_txg_timeout thành 10 và zfs_txg_ cẩn thận,

Hi vọng điêu nay co ich. Chúc may mắn!

Tôi nghi ngờ phần cứng ...

Tại sao bạn lại để nó chạy trong 15 ngày? Điều đó không bình thường. Dừng chà - zpool scrub -s tankvà kiểm tra hệ thống.

• Những bộ điều khiển bạn đang sử dụng?
• Đây có phải là cây chà đầu tiên bạn từng chạy trên bể bơi này không?
• Có một vấn đề khiến bạn phải chạy chà ở nơi đầu tiên?

Câu trả lời của tôi đến hơi muộn, nhưng nếu điều này xảy ra với bất kỳ ai khác, thì đây là vấn đề của tôi: chỉ cần thử "dmesg". Trong trường hợp của tôi, tôi đã không thực hiện chà, nhưng tôi đã sao chép các tệp vào đĩa và tôi rõ ràng đã nghe thấy các đĩa đang hoạt động trong vài giây, sau đó tất cả dừng lại trong một thời gian dài hơn và tiếp tục hoạt động. Điều này là do lỗi của một bộ điều khiển SATA và dmesg đã cho tôi tất cả các lỗi. Tôi đã nghĩ rằng đó là một đĩa thất bại lúc đầu, nhưng sau đó tôi nhận ra nó thực sự là bộ điều khiển.

Scrub sử dụng thời gian chết hệ thống có sẵn, ngay cả trên một máy chủ không tải, đó là về tính khả dụng. Ram và Bộ xử lý là chìa khóa để sử dụng, không phải đĩa. Càng có nhiều trong số này, hiệu suất chà của bạn sẽ càng tốt. Tuy nhiên, chắc chắn, trong trường hợp này, đĩa của bạn được bố trí càng tốt, về mặt ZPool, hiệu suất chà của bạn cũng sẽ tốt hơn.

Vì vậy, nếu hiệu suất của bạn chậm, và đó có vẻ là trường hợp, tôi sẽ xem đây là những lý do tiềm năng.