« Rev
@ru_zfs   549
Fwd »


nikolay
мне непонятен вывод arc_summary
nikolay
почему ARC size current больше чем я выделил? и почему Metadata cache size также больше?
nikolay
https://github.com/openzfs/zfs/issues/9966?ysclid=lb8kga41q8153787841
вот тут писали что это бага
George
и по дефолту zfs постарается отдать обратно, по дефолту он за собой около 100мбайт только оставит
George
вот тут писали что это бага
похожие баги были, когда причины попытки очистить срабатывали неожидаемо
nikolay
нет, ядро будет требовать в любом случае, когда ядру нужна память
мм.. ядру память просто так не нужна. если в ядро пришел другой процесс и ядро видит что памяти нет, на основании чего оно будет забирать у zfs? ну и как бы arc_summary говорит о том что все 128 Гб получены..
George
если у ядра другой памяти не будет
edo1
Я тоже так делал. Чтение меты с ssd дешёвое, а данных с hdd дорогое
edo1
Правда, оно не особо совместимо с переносом мелких record на special
George
плюс все 128Г съедены, сам zfs будет по кругу пытаться ужаться к этим размерам
George
мм.. это такая логика реально реализована или ваше предположение?
ну вы попробуйте забить arc и потом память зааллоцировать)))
George
чтобы точно не хватило без памяти из arc
nikolay
то я только для меты special планировал использовать. у меня нет большого количества мелких record
edo1
если ты про это swift special_small_blocks 0 default
В этом конкретном случае понятно
George
вот да, но блин почему zfs хочет больше чем 128?))
ну вы понимаете как кеш работает? любое чтение через него пройдёт, если кеш включен для данных
George
плюс такое # 64MB prefetch read ahead (default 8MB) options zfs zfetch_max_distance=67108864 приведёт к гарантированно большему расходу кеша и шансу его вымывать без надобности, вы точно уверены что все 60+мбайт будут сразу прочитаны?
nikolay
плюс такое # 64MB prefetch read ahead (default 8MB) options zfs zfetch_max_distance=67108864 приведёт к гарантированно большему расходу кеша и шансу его вымывать без надобности, вы точно уверены что все 60+мбайт будут сразу прочитаны?
не уверен, в целом я понял что кое-где перестарался и на реальных данных настройки ведут себя не так на при синтетической нагрузке. плохо что все это уже в проде и теперь придется оч аккуратно менять настройки
nikolay
а оптимизации на синтетике вам прям сильно меняли ситуацию? если нет, то не рекомендую дефолты менять в будущем
ну как сильно.. моя задача была сделать так чтобы для zfs под определенную нагрузку хватало 128 Гб и мета активно использовала special dev
nikolay
в тестах это работало
George
в тестах это работало
ну как раз вопрос не в том что работало ли а менялось ли что-то в позитивную сторону относительно дефолтов
George
я честно скажу, что некоторые параметры даже на выкручивании в 100 раз у меня на тестах базовых не показывали разницу, но точно бы стрельнули в проде
nikolay
ну да, задание например параметра options zfs zfs_arc_meta_limit_percent=40 изменяет поведение системы
nikolay
arc используется не так аггрессивно
nikolay
из 128 Гб у меня стабильно было свободно порядка 30-40 Гб в тестах
nikolay
а в проде наоборот
Сергей
ну как сильно.. моя задача была сделать так чтобы для zfs под определенную нагрузку хватало 128 Гб и мета активно использовала special dev
Странное требование) может дешевле кэшами обвншаться? Благо стоит это все копейки
George
из 128 Гб у меня стабильно было свободно порядка 30-40 Гб в тестах
либо выборка тестовая была меньше 128Г либо синтетика не сходится с фактичской нагрузкой
nikolay
тестовая выборка была порядка 60 Тб)
George
тестовая выборка была порядка 60 Тб)
вы все 60тб вычитывали? если да, то круто)
Сергей
в полистайте выше, я кэшами обвешан по самое не хочу)
А у дисков иопсы при этом всем нормальные? Может это Арк сбрасывается но тормозной л2арк? У меня так txg тупило при одном медленном диске в массиве
nikolay
вы все 60тб вычитывали? если да, то круто)
ну не все конешно. но горячий объем данных не меньше Тб был точно
nikolay
А у дисков иопсы при этом всем нормальные? Может это Арк сбрасывается но тормозной л2арк? У меня так txg тупило при одном медленном диске в массиве
у меня изначально не было l2arc, и как я писал выше добавление l2arc помогло снизить load average для приемлемых значений, но aкc_prune и arc_evict остаются.
nikolay
Сброс к дефолту-то помог?)
ну я не хочу делать резких телодвижений) буду постепенно подкручивать параметры. сейчас помогает echo 3 > в dirty cache
nikolay
жить можно
Shaker
Metadata cache size (hard limit): 40.0 % 51.2 GiB Metadata cache size (current): 273.4 % 140.0 GiB вообще похоже на https://github.com/openzfs/zfs/issues/14005
У меня была такая история c 0.8.3 ( идет в дефолте с ubuntu 20.04 ), лечилось апгрейдом zfs или фиксированием размера через zfs_arc_max/zfs_arc_min.
Shaker
Он у меня сделан совпадающим там, 68719476736 оба значения. Всего памяти 256G. И сразу проблема ушла.
Shaker
у меня явно задан и один и второй параметр
А настройки применились ? Что-то такое было ? sudo update-initramfs -u -k all reboot Если ты менял через /etc/modprobe.d/zfs.conf , или где там оно у тебя.
nikolay
у меня вот это options zfs zfs_arc_meta_limit_percent=100
nikolay
и dnode я не регулировал
Fedor
Когда горячих данных было больше, чем все арки вместе взятые
nikolay
Ну я бы смотрел на metadata cache size
кажется я нашел виновника торжества. несколько десятков раз в секунду на всех нодах один из внутренних процессов объектного хранилища делает listdir на подкаталоги, которые смонтированы как zfs dataset'ы. зачем он это делает непонятно, это отдельная история
nikolay
правильно я понимаю что это приводит к постоянной подкачке меты в ARC и постепенному переполнению выделенных 128 Гб
nikolay
при этом на одной ноде я сбросил все параметры zfs в дефолтовые, порог для metadata cache size = 75% по умолчанию, но вывод arc_summary показывает что surrent size выше.. получается несмотря на то что arc_evict молотит cpu и пытается вытеснить лишние данные из кэша он не успевает этого сделать и новые данные подкачиваются несмотря на лимиты?
nikolay
интересно можно как-то компенсировать постоянный listdir на уровне zfs?
central
Что за обьем что нужно 100 гб памяти для списка файлов?
Владимир
central
?
nikolay
Что за обьем что нужно 100 гб памяти для списка файлов?
а почему вы решили что все метаданные это только список файлов?
nikolay
swift/obj15 186G 71M 186G 1% /srv/node/obj15 swift/obj14 186G 71M 186G 1% /srv/node/obj14 swift/obj16 186G 71M 186G 1% /srv/node/obj16 swift/obj13 186G 71M 186G 1% /srv/node/obj13
nikolay
у меня уже 280 млн файлов выходит
nikolay
и 164к каталогов в каждой точке монтирования, далее подкаталоги
nikolay
при этом листинг директорий идет постоянно..
Вадим «Дым» Илларионов ☭
Кто-нибудь пробовал слать системные мессаги по токсу? Ищу защищённый вариант отправки системных сообщений (типа результата быкапов, каких-то сбоев) в мессенджер: 1) без того, чтоб развёртывать и админить спецсервис, писать в который будет... никто кроме аварийных скриптов на серваках, а читать — пара админов (то есть, жабер — фтопку); 2) не сервис, разруливаемый кем-то левым (так что телега/скайп и иже с ними тоже идут лесом). При таком раскладе напрашивается консольный toxic или токс-бот с отправкой сообщений в группу. Вот только не пробовал его и даже просто початиться по нему не доводилось. И ничего внятного по теме не нагугливается. Есть съевшие собаку на такой задаче?
Vladislav
чем тебе jabber не подошел?
Вадим «Дым» Илларионов ☭
чем тебе jabber не подошел?
См. п. 1.
Vladislav
См. п. 1.
настраиваешь и забываешь.
Вадим «Дым» Илларионов ☭
настраиваешь и забываешь.
1. Бота так же. Потом тиражируешь на все отслеживаемые узлы/эплаенсы/контейнеры — и забываешь. Знай, следи за соотв.чатиками. 2. В нескольких окучиваемых конторах конфигурил ежабера с привязкой к ЛДАПу, но народ предпочитал аськи-скайпы и прочую хрень.
Вадим «Дым» Илларионов ☭
открываешь табличку с клиентами tox, смотришь, грустишь и закрываешь
Довольно токсика (или бота) для сервака, кутокса для рабочей машинки и атокса для ведроида. Мне с серваками не ВКСы устраивать.
Vladislav
внимательно читай табличку.
Vladislav
в любом случае это оффтоп
« Rev
@ru_zfs   549
Fwd »