Настройка ZFS очистки, 141KB / с работает в течение 15 дней

14

Довольно простая система с зеркалом + полоса на дисках sas с частотой вращения 7,2 тыс. Об / мин, не особенно загруженная. Нет дедупликации, сжатие на всех наборах данных. Скраб работает уже 15 дней со скоростью мертвой улитки. Есть какая-то оптимизация, которая должна быть сделана, или это может быть из-за неисправного hw?

  • 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 МБ / с. Между этими записями в основном нет чтения или записи.

                          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%

$ 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  nexenta 
— 3molo
источник
Какое множественное вхождение иостата -XnE | ошибки grep говорит? сделать приращение количества ошибок?
Ноль во всех столбцах
— 3моло
Что smartctl -A /dev/diskговорит о каждом диске (возможно, придется установить smartctl, не уверен, если он поставляется с базовой установки).
— Крис С
1
Ничего интересного, кроме «Non-medium error count: 8071» на одном диске. Все диски находятся в JBOD (Dell MD1200) на одном и том же (одноместном) sas lane
— 3моло,

Ответы:

11

Операции по очистке ZFS основаны на некоторых довольно мёртвых принципах. В частности, он тратит время только на очистку, когда больше ничего не происходит. Если вы создадите пул с небольшим доступом к данным на довольно постоянной основе, scrub будет эффективно морить себя голодом и почти ничего не делать.

Tunables для изучения, с моими быстрыми заметками о том, что он делает (хотя я в последний раз изучал это некоторое время назад):

  • zfs_scan_idle - если пользовательский ввод / вывод происходит в течение этого большого количества тактов, задержите очистку ввода / вывода с помощью тактовых импульсов zfs_scrub_delay
  • zfs_scrub_delay - сколько тактов для задержки операции очистки, если запущено zfs_scan_idle
  • zfs_top_maxinflight - максимальное количество операций ввода-вывода для скраба на vdev верхнего уровня
  • zfs_scrub_limit - максимальное количество операций ввода-вывода скраба на лист vdev
  • zfs_scan_min_time_ms - минимальное количество мс для каждой операции очистки
  • zfs_no_scrub_io - нет заметок
  • zfs_no_scrub_prefetch - нет заметок, имя, по-видимому, подразумевает, что не вызывает предварительную выборку для операций очистки

Все это можно изменить на лету, используя «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 <number> | 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 может тратить гораздо больше времени на скрабы, может
— лишить
Я думаю, что вы предоставили очень ценный вклад, но было бы гораздо полезнее, если бы вы могли добавить комментарии в один хороший ответ.
— 3моло
2
Больше тюнинга, возможно, помогло, но не обязательно. Важно отметить, что скраб ZFS прокручивает структуру данных, а НЕ сектор за сектором на дисках. То есть, в зависимости от того, как структура данных zfs выглядит на ваших дисках, операция очистки может выглядеть невероятно случайной - ваши диски могут быть способны к> 100 МБ / с последовательного чтения, но полностью случайное чтение будет другой историей. , Средний размер блока также имеет значение здесь.
— Nex7
3

Я подозреваю, что оборудование ...

Почему ты позволил этому бежать в течение 15 дней? Это не нормально. Остановите очистку - zpool scrub -s tankи проверьте систему.

  • Какие контроллеры вы используете?
  • Это первый скраб, который вы когда-либо запускали в этом пуле?
  • Была ли проблема, которая побудила вас запустить скраб?
— ewwhite
источник
1
LSI SAS9200-8e (IT прошивка). Не первый скраб. Нет, никаких реальных проблем (но я уже давно ставлю под сомнение производительность чтения / записи).
— 3моло
Обновляется с задержкой и временем ожидания, начиная подозревать, что всегда есть время для обслуживания запросов, и это отдает приоритет очистке настолько низко, что она останавливается. Любое понимание очень полезно!
— 3моло
Скрабы важны для периодического запуска. Ожидание, пока у вас не возникнет проблема с запуском скраба, требует, чтобы эта проблема вылилась в потерю данных. Скрабы предназначены для того, чтобы ловить молчаливое повреждение данных (битрот). Медленная очистка не является признаком системной проблемы, просто пул достаточно занят, чтобы не ускорить очистку.
— 17
0

Мой ответ приходит немного поздно, но если подобное случается с кем-то еще, вот мое мнение: просто попробуйте "dmesg". В моем случае я не выполнял очистку, но копировал файлы на диски, и я отчетливо слышал, как диски были активны в течение нескольких секунд, затем все останавливались на более длительное время, снова работали и так далее. Это произошло из-за сбоя одного контроллера SATA, и dmesg дал мне все ошибки. Сначала я думал, что это сбойный диск, но потом понял, что это на самом деле контроллер.

— jytou
источник
-3

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

Итак, если ваша работа была медленной, и это действительно так, я бы посчитал это потенциальными причинами.

— user169761
источник
1
Я не вижу признаков того, что каких-либо ресурсов мало.
— 3моло
1
Это в значительной степени совершенно неверно. Процессор и оперативная память практически не влияют на операции очистки (при условии, что они вообще бесплатны). Наличие большого количества свободной оперативной памяти и процессора не ускорит операции очистки. Scrub ограничен отслеживанием входящих операций ввода-вывода в пул, а не проверкой на «доступное время простоя системы», что бы это ни было.
— Nex7
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.