Довольно простая система с зеркалом + полоса на sas дисках 7.2k об / мин, особо не загруженная. Без дедупликации, сжатия для всех наборов данных. Скраб работает уже 15 дней со скоростью дохлой улитки. Есть ли какая-то оптимизация, которую нужно сделать, или это может быть связано с каким-то неисправным hw?
Немного информации:
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
------------------------- ----- ----- ----- ----- ----- ----- ----- -----
Сообщает ли мне 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
pre mdb tweak, обратите внимание на довольно высокий столбец 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
post 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 работают по довольно безумным принципам. В частности, он тратит время на чистку только тогда, когда больше ничего не происходит. Если вы протыкаете пул только небольшим количеством доступа к данным на довольно постоянной основе, 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 по умолчанию, но осторожно, это может привести к нехватке нормального ввода / вывода, если настройки задержки также были установлены в основном на 0!
Надеюсь это поможет. Удачи!
Подозреваю, что железо ...
Почему вы позволили этому поработать 15 дней? Это ненормально. Прекратите скраб - zpool scrub -s tank и проверьте систему.
Мой ответ приходит немного поздно, но если подобное случается с кем-то еще, вот мой подход: просто попробуйте «dmesg». В моем случае я не выполнял очистку, но я копировал файлы на диски, и я ясно слышал, как диски были активны в течение нескольких секунд, затем все останавливались на более длительное время, снова работали и так далее. Это произошло из-за отказа одного контроллера SATA, и dmesg выдал мне все ошибки. Сначала я подумал, что это неисправный диск, но потом понял, что на самом деле это контроллер.
Scrub использует доступное время простоя системы даже на выгруженном сервере, это касается доступности. Оперативная память и процессор - это ключи к очистке утилизации, а не диск. Чем больше их доступно, тем лучше будет ваша чистка. Однако, безусловно, в этом случае, чем лучше расположены ваши диски с точки зрения ZPools, тем лучше будет производительность очистки.
Итак, если ваша производительность была медленной, а это действительно так, я бы рассмотрел это как возможные причины.