Налаштування очищення ZFS, 141 Кб / с працює 15 днів

14

Досить основна система працює дзеркало + смужка на 7,2 Кб / хв сас диски, не особливо завантажені. Немає знімання, стиснення на всіх наборах даних. Скраб працює вже 15 днів зі швидкістю мертвого равлика. Чи є якась оптимізація, яку потрібно зробити, чи це може бути пов’язано з дефектом hw?

Dell R510 з корпусом MD1200.
2x Xeon E5620
48 Гб
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 Мб / с. Між тими записами в основному немає читання чи запису.

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

Чи говорять мені іостати про те, що я витрачаю більше часу на очікування диска, тоді мені доведеться це робити? Зокрема стовпець% 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

перед тим, як змінити mdb, помітьте досить високий стовпчик b%

$ іостат -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 tweak, помічайте стовпчик 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 nexenta

— 3моло
джерело

Яка множинна поява іостату -XnE | grep Помилки каже? Зробити деякий приріст підрахунку помилок?

Нуль у всіх стовпцях

— 3моло

Що smartctl -A /dev/diskговорить про кожен накопичувач (можливо, доведеться встановити smartctl, не впевнений, чи він поставляється з базовою установкою).

— Кріс С

1

Нічого не цікавить, окрім "Кількість помилок середнього рівня: 8071" на одному диску. Усі диски сидять у JBOD (Dell MD1200) на одній (одиночній)

— провулці

11

Операції скрабування ZFS працюють за деякими принципами, що відмерли від мозку. Найголовніше, що він витрачає час на вичісування лише тоді, коли більше нічого не відбувається. Якщо тикаєш по пулу з невеликим доступом до даних на досить постійній основі, скраб буде ефективно голодувати і майже нічого не робити.

Налаштування для вивчення, з моїми швидкими записками про те, що це робить (хоча я востаннє розглядав це деякий час тому):

zfs_scan_idle - якщо користувачі входять / виходять в такі багато кліщових годин, затримуйте скраб вводу / виводу за допомогою годинника zfs_scrub_delay.
zfs_scrub_delay - скільки годинних галочок для затримки роботи скрабу, якщо його запускає zfs_scan_idle
zfs_top_maxinflight - максимальна кількість вводу-виводу скрабу на кожен vdev верхнього рівня
zfs_scrub_limit - максимальна кількість введення-виводу скрабу на лист вдев
zfs_scan_min_time_ms - мінімальний мс, витрачений на txg на операції скрабування
zfs_no_scrub_io - жодних приміток
zfs_no_scrub_prefetch - жодні нотатки, ім'я, мабуть, не означає, що не спричиняє попереднього вибору на операції scrub

Все це змінюється під час руху, використовуючи "echo [tunable] / W0t [number]" для зміни, і "echo [tunable] / D" для перегляду поточних налаштувань (що я рекомендую робити перед зміною).

Тож теоретично і загалом, якщо ви, скажімо, змінили zfs_scan_idle до 10 (або 1 - або 0, якщо це підтримує, потрібно перевірити код) і zfs_scrub_delay до 1 (або 0, якщо це підтримує це), і якщо ваше налаштування txg_synctime_ms становить 5000 або більше, можливо, трохи змінить zfs_scan_min_time_ms, воно повинно стати набагато агресивнішим щодо того, щоб насправді робити операції скрабування, навіть якщо в них виникає деякий рівень вводу-виводу користувача.

У вашому конкретному випадку,% 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 на 5000, а потім спробуйте збільшити zfs_scan_min_time_ms на 3000 або 4000. Це говорить про те, що ZFS може витратити набагато довше на скраби, порівняно з налаштуваннями за замовчуванням для старих установок NexentaStor, які використовують 5/1 як стандартні настройки - але обережно,

Сподіваюсь, це допомагає. Удачі!

— Nex7
джерело

Я вважаю, що слід зазначити, що ви змінюєте ці параметри в bash, використовуючи "echo <tunable> / W0t <номер> | mdb -kw". І ви переглядаєте поточні значення за допомогою "echo <tunable> / D | mdb -k". У моїх записках сказано, що все це може бути змінено під час польоту, але, здається, жодна з них не потребує модифікації / etc / system та перезавантаження, щоб набути чинності.

— Nex7

Я також повинен прочитати все питання, перш ніж відповісти - і перестати переглядати ServerFault під час конференційних дзвінків. :)

— Nex7

Звіт% 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 на 5000, а потім спробуйте підвищуючи zfs_scan_min_time_ms до 3000 або 4000. Це говорить про те, що ZFS може витратити набагато довше на скраби, може голодувати нормальним вводу-виводу!

— Nex7

Я думаю, ви надаєте дуже цінний внесок, але було б набагато корисніше, якби ви могли додати коментарі до однієї гарної відповіді.

— 3моло

2

Більше налаштування, можливо, допомогло, але не обов’язково. Важливо зазначити, що скраб ZFS прокручується по структурі даних, а не по секторах на дисках. Що означає, залежно від того, як виглядає структура даних zfs на ваших дисках, операція скрабування може виглядати неймовірно випадково - ваші диски можуть вміти> 100 Мб / с послідовного зчитування, але повністю випадкове читання буде цілком іншою історією . Середній розмір блоку також має значення тут.

— Nex7

3

Підозрюю, що обладнання ...

Чому б ви пустили це на 15 днів? Це не нормально. Зупиніть скраб - zpool scrub -s tankі перевірте систему.

Які контролери ви використовуєте?
Це перший скраб, який ви коли-небудь бігали в цьому басейні?
Чи була проблема, яка спонукала вас запустити скраб в першу чергу?

— ewwhite
джерело

1

LSI SAS9200-8e (IT-прошивка). Не перший скраб. Ні, жодних реальних проблем (але я деякий час ставив під сумнів виконання послідовного читання / запису).

— 3моло

Оновлений із затримкою та часом очікування, починаючи підозрювати, що завжди є час на запити на обслуговування, і пріоритет скрабу настільки низький, що він повзає. Будь-яке розуміння дуже корисне!

— 3моло

Скраби важливо періодично запускати. Очікуючи, поки у вас виникне проблема запустити скраб, потрібно просити цю проблему втратити дані. Скраби є, щоб зловити мовчазні пошкодження даних (бітрот). Повільний працюючий скраб не є ознакою системної проблеми, просто пул, який достатньо зайнятий, щоб скраб не прискорився.

— lschweiss

0

Моя відповідь приходить трохи пізно, але якщо подібна річ трапиться з кимось іншим, ось мій погляд: просто спробуйте "dmesg". У моєму випадку я не робив скраб, але я копіював файли на диски, і я чітко чув, як диски активні протягом декількох секунд, потім всі зупинялися на довший час, і знову працювали і так далі. Це було пов'язано з відмовою одного контролера SATA, і dmesg видав мені всі помилки. Спочатку я думав, що це несправний диск, але потім зрозумів, що це насправді контролер.

— jytou
джерело

-3

Scrub використовує доступний системний час простою, навіть на незавантаженому сервері, мова йде про доступність. Ram і Processor - це ключі для очищення використання, а не диск. Чим більше їх доступно, тим краще буде робота ваших скрабів. Однак, безумовно, в цьому випадку, чим якісніше будуть викладені ваші диски з точки зору ZPools, тим краще буде і ваша продуктивність для скрабу.

Отже, якщо ваша продуктивність повільна, і це, мабуть, так, я б розглядав це як потенційні причини.

— користувач169761
джерело

1

Я не бачу жодного показника того, що будь-яких ресурсів мало.

— 3моло

1

Це майже абсолютно неправдиво. Процесор і оперативна пам’ять фактично нульовий вплив на операції скрабування (якщо вважати, що взагалі є якісь безкоштовні). Маючи багато вільної оперативної пам’яті та процесора, це не прискорить операції скрабування. Скраб обмежений переглядом вхідного / виводу в пул, а не шляхом перевірки "наявного простою системи", що б там не було.

— Nex7