nikolay
свободной памяти порядка от 20 до 30 Гб
edo1
Хм
nikolay
и еще пытался тюнить кеш для меты, вот так сейчас задано
nikolay
# 40%RAM limit metadata cache
options zfs zfs_arc_meta_limit_percent=40
nikolay
и префетч
nikolay
# 64MB prefetch read ahead (default 8MB)
options zfs zfetch_max_distance=67108864
nikolay
может я перетюнил чего..
nikolay
находил в бактреккере вот такое
nikolay
https://github.com/openzfs/zfs/issues/9966?ysclid=lb8kga41q8153787841
nikolay
но это довольно старая тема, версия zfs у меня 2.1.6
nikolay
линукс centos stream 8
nikolay
да, arc_summary показывает что под arc как бы выделено больше чем 128 Gb
nikolay
ARC size (current): 109.4 % 140.1 GiB
Target size (adaptive): 100.0 % 128.0 GiB
Min size (hard limit): 25.0 % 32.0 GiB
Max size (high water): 4:1 128.0 GiB
Most Frequently Used (MFU) cache size: 61.2 % 31.8 GiB
Most Recently Used (MRU) cache size: 38.8 % 20.1 GiB
Metadata cache size (hard limit): 40.0 % 51.2 GiB
Metadata cache size (current): 273.4 % 140.0 GiB
nikolay
140 gib под мету, это зачем так?)
edo1
df -hi что говорит?
nikolay
сброс ARC через очистку dirty buffers помогает, но временно
Vladislav
Сперва умер один из дисков в зеркале (диск X)
Ему на смену из HS пришёл диск, который с 681 ошибок по чексуммам
Я принудительно сделал replace диск X на сторонний диск, который был не в пуле (da0)
После resilvering ничего не поменялось и da25p1 продолжил висеть со статусом Degraded
Я сделал da25 Offline и после этого ВСЕ hot-spare решили, что ВРЕМЯ ПРИШЛО
Ладно бэкап есть пятничный, а то было бы ссыкотно мальца
Ivan
nikolay
Да я про количество файлов
swift/obj06 187G 61M 187G 1% /srv/node/obj06
swift/obj07 187G 61M 187G 1% /srv/node/obj07
swift/obj08 187G 61M 187G 1% /srv/node/obj08
swift/obj05 187G 61M 187G 1% /srv/node/obj05
nikolay
например не кончилось ли место под special
special - - - - - -
mirror-6 327G 9.66T 300 5.56K 1.19M 56.2M
scsi-SHUAWEI_XSG1_2102352XPK10M80000070032 - - 115 2.78K 463K 28.1M
scsi-SHUAWEI_XSG1_2102352XPK10M80000060005 - - 185 2.78K 752K 28.1M
edo1
nikolay
61м х4? Вроде немного
ну да, сервера в проде пару недель всего, ничего еще не успели залить..
edo1
То есть файлы не особо крупные
edo1
А паттерн доступа какой?
nikolay
и нагрузки на них какой-то большой нет, порядка 200 Мб/с на запись, 30-40 чтение
edo1
Может find по кругу гоняется
Ivan
и нагрузки на них какой-то большой нет, порядка 200 Мб/с на запись, 30-40 чтение
для одного raidz vdev это многовато 😃
nikolay
pool: swift
state: ONLINE
scan: resilvered 10.9G in 00:00:55 with 0 errors on Fri Nov 18 03:19:06 2022
config:
NAME STATE READ WRITE CKSUM
swift ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJUJN2N ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2THM452D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2THWUG2D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ5G0MD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ65S5D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ7U59D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ7VXSD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ8MM5D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ8ZZSD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ9D34D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJ9E0ND ONLINE 0 0 0
raidz2-1 ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJD39YD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJED1YD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJED6VD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJENR4D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJG1HWD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJGJYWD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJGK45D ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJGNBXD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJH4VND ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJH4VRD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJH4VUD ONLINE 0 0 0
raidz2-2 ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHAJBD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHDNAD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHDNKD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHDVHD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHGUMD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHGWKD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHGZGD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHJ2ZD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHT1TD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHT3SD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHU3ND ONLINE 0 0 0
raidz2-3 ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_2TJHU3UD ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHEW5HX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHTUXTX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHU3Y7X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHVNU6X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHW0P8X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHW7RHX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHW7VWX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEHXZV3X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ24K8X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ24ZGX ONLINE 0 0 0
raidz2-4 ONLINE 0 0 0
nikolay
scsi-SHGST_HUH721010AL5204_JEJ252UX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ25LMX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ30MDX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ316NX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ31B8X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ31D9X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ31XRX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ3DYNX ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ3EE4X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJ3EU1X ONLINE 0 0 0
scsi-SHGST_HUH721010AL5204_JEJTAY5N ONLINE 0 0 0
special
mirror-6 ONLINE 0 0 0
scsi-SHUAWEI_XSG1_2102352XPK10M80000070032 ONLINE 0 0 0
scsi-SHUAWEI_XSG1_2102352XPK10M80000060005 ONLINE 0 0 0
logs
mirror-5 ONLINE 0 0 0
scsi-SHUAWEI_XSG1_2102352XPK10M80000060001 ONLINE 0 0 0
scsi-SHUAWEI_XSG1_2102352XPK10M80000070027 ONLINE 0 0 0
cache
scsi-SHUAWEI_XSG1_2102352XPK10M80000070042 ONLINE 0 0 0
spares
scsi-SHGST_HUH721010AL5204_JEJTRHHN AVAIL
scsi-SHGST_HUH721010AL5204_JEJTUPPN AVAIL
scsi-SHGST_HUH721010AL5204_JEJU31EN AVAIL
scsi-SHGST_HUH721010AL5204_JEJTE6UN AVAIL
nikolay
5 vdev в raidz2 + slog + special. кстати добавление l2arc помогло снизить load average, но не помогло выровнять оверхед по arc
nikolay
Реплика в сторону: я бы попробовал draid на таком числе дисков
может быть, если бы у меня было время на тесты производительности. в гугле пишут что оно вроде как не быстрее zraid, а в ряде кейсов медленнее
edo1
может быть, если бы у меня было время на тесты производительности. в гугле пишут что оно вроде как не быстрее zraid, а в ряде кейсов медленнее
так он не должен отличаться, просто удобнее
edo1
У тебя не куча raidz с n+2 каждый, а один пул дисков, а избыточность всё та же n+2
edo1
То есть можно собрать, например, на 13 дисках 5+2
nikolay
Может find по кругу гоняется
системный find исключено. но объектник может делать LIST опять же только при определенных запросах со стороны админов, а админ я)
Ivan
а SHUAWEI_XSG1 это че такое ?
nikolay
так он не должен отличаться, просто удобнее
ну удобство тут такое. плюс draid в том что он ребилдид быстрее чем zraid.
nikolay
а SHUAWEI_XSG1 это че такое ?
это луны с дорады) временно выданы по FC из-за недоехавших локальных ssd
Ivan
это луны с дорады) временно выданы по FC из-за недоехавших локальных ssd
оно не может быть узким местом ?
nikolay
латенси на них меньше 1 ms, тут проблем быть не должно..
nikolay
по крайней мере если смотреть на вывод zpool iostat -l
nikolay
у меня смутные подозрения что я где-то перемудрил с тюнингом)) но вот блин где..
nikolay
вот полный список параметров, которые я выставляю
nikolay
# ARC 32GB min
options zfs zfs_arc_min=34359738368
# ARC 128GB max
options zfs zfs_arc_max=137438953472
#options zfs zfs_immediate_write_sz=
#options zfs zfs_commit_timeout_pct=20
# 40%RAM limit metadata cache
options zfs zfs_arc_meta_limit_percent=40
# 64MB prefetch read ahead (default 8MB)
options zfs zfetch_max_distance=67108864
# 4MB read chank size (default 1MB)
options zfs zfs_vnops_read_chunk_size=1048576
# async read max active IO queue (default 3 IOPs)
options zfs zfs_vdev_async_read_max_active=128
# async read min active IO queue (default 1 IOPs)
options zfs zfs_vdev_async_read_min_active=64
# async write max active IO queue (default 10 IOPs)
options zfs zfs_vdev_async_write_max_active=128
# async write min active IO queue (default 2 IOPs)
options zfs zfs_vdev_async_write_min_active=64
# async write min dirty data (default 30%)
options zfs zfs_vdev_async_write_active_min_dirty_percent=30
# async write max dirty data (default 60%)
options zfs zfs_vdev_async_write_active_max_dirty_percent=70
# sync read max active IO queue (default 10 IOPs)
options zfs zfs_vdev_sync_read_max_active=128
# sync read min active IO queue (default 10 IOPs)
options zfs zfs_vdev_sync_read_min_active=64
# sync write max active IO queue (default 10 IOPs)
options zfs zfs_vdev_sync_write_max_active=128
# sync write min active IO queue (default 2 IOPs)
options zfs zfs_vdev_sync_write_min_active=64
# prohibit flushing VDEV DRAM cache
options zfs zfs_nocacheflush=0
# prohibit flushing ZIL VDEV DRAM cache
options zfs zil_nocacheflush=1
# dirty data max level for write (default 3200 MB)
options zfs zfs_dirty_data_max=8589934592
# aggregate write txg timeout (def 5s)
options zfs zfs_txg_timeout=20
#options zfs l2arc_write_max=8388608
# for recieve only pool (default 1048576)
options zfs zfs_vdev_aggregation_limit=4718592
# set for recordsize 128K default 32768
options zfs zfs_vdev_read_gap_limit=262144
# set for ashift=12 default 4096
options zfs zfs_vdev_write_gap_limit=16384
nikolay
# prohibit flushing VDEV DRAM cache
options zfs zfs_nocacheflush=0
# prohibit flushing ZIL VDEV DRAM cache
options zfs zil_nocacheflush=1
nikolay
вот эти параметры могут в теории влиять на наполняемость ARC?
edo1
у меня смутные подозрения что я где-то перемудрил с тюнингом)) но вот блин где..
Ну я бы смотрел на metadata cache size
edo1
Что оно такое выросло
edo1
С первого взгляда в этом проблема
nikolay
# 40%RAM limit metadata cache
options zfs zfs_arc_meta_limit_percent=40
nikolay
либо я не понимаю значения этого параметра
edo1
Ну лимит
edo1
Но может у тебя там охулиард открытых файлов
Sergey
Всем привет. Вышел новый релиз моего Live CD. Ядро 6.0.11, ZFS 2.1.7. https://git.s-morozov.net/sergey/archlive-zfs/releases/tag/2022.12.06
George
вот эти параметры могут в теории влиять на наполняемость ARC?
если такой вопрос поднимается - стоит убирать тюнинги😄
сорри за неконструктивный ответ, но тюнить без понимания - не стоит
George
если есть вопросы - просто тюнинги убрать и смотреть влияние
nikolay
если есть вопросы - просто тюнинги убрать и смотреть влияние
согласен, но на этапе нагрузочных тестов все работало ровно, поэтому я решил что тюнинг рабочий..
nikolay
пока попробую "на лету" поменять ряд параметров, сброшу в дефолт.
George
согласен, но на этапе нагрузочных тестов все работало ровно, поэтому я решил что тюнинг рабочий..
options zfs zfs_arc_meta_limit_percent=40
а зачем? обычно все наоборот хотят его в 100 выкрутить
nikolay
options zfs zfs_arc_meta_limit_percent=40
а зачем? обычно все наоборот хотят его в 100 выкрутить
ну я рассуждал так - у меня есть special большого объема, пусть мета пишется туда как можно быстрее и не занимает память
nikolay
так как памяти выделяется только 128Гб, хочется чтобы не вымывался кэш, был более эффективный prefetch и лишние данные в памяти не задерживались
nikolay
либо я просто некорректно рассчитал конфигурацию и 128 Гб zfs'у тупо не хватает. и я бы согласился с этим, если бы была нагрузка.. а ее мало
nikolay
zpool iostat -l 3
capacity operations bandwidth total_wait disk_wait syncq_wait asyncq_wait scrub trim
pool alloc free read write read write read write read write read write read write wait wait
---------- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
swift 8.52T 502T 1.42K 4.66K 7.73M 39.4M 1ms 512us 1ms 493us 866ns 488ns 871ns 21us 151ms -
swift 8.52T 502T 5.54K 11.9K 66.6M 135M 2ms 509us 2ms 507us 645ns 548ns - 1us - -
swift 8.52T 502T 5.58K 13.2K 66.4M 147M 1ms 493us 1ms 491us 667ns 533ns - 1us - -
swift 8.52T 502T 5.66K 11.5K 69.0M 132M 2ms 502us 2ms 500us 639ns 533ns - 2us - -
swift 8.52T 502T 5.36K 12.5K 64.1M 144M 2ms 590us 2ms 588us 629ns 510ns - 1us - -
swift 8.52T 502T 5.13K 12.2K 61.0M 138M 2ms 482us 2ms 480us 656ns 506ns - 1us - -
nikolay
вывод zpool iostat с одного сервера, на остальных аналогично
George
вывод zpool iostat с одного сервера, на остальных аналогично
arc_prune это попытка в arc что-то почистить, вызвано может быть либо запросом от ядра отдать память, либо настройками, в частности тем же zfs_arc_meta_limit_percent когда есть доп. условия когда что надо чистить. В идеале выяснить для начала какая из причин вызывает это