Свежие комментарии

Title Comment
Вот тут собираются отключить

Вот тут собираются отключить отключение сжатия, есть ссылки на этот твой пост, но люди жаждут подробностей, можешь прийти туда и дать им подробности?

https://github.com/zfsonlinux/zfs/issues/7896

У меня нет arc_max, основная

У меня нет arc_max, основная роль — раздача 3 терабайт торрентов. Памяти 32, после 88 дней аптайма вот такая картина, как я привёл.
Хитрейт (эффективный) 90%. Когда-то давно до всех этих новых фич на сервере было 16 гигов памяти и, да, была иногда другая проблема — ARC съедал столько, сколько мог и начинался своппинг — но ARC Вскгда занимал память под завязку хитрейт был 95%.

И, повторю в третий раз, я такой не уникальный.

обрати внимание на разницу WIRED и ARC

Тоже обращал внимание, что ARC перестал дорастать до vfs.zfs.arc_max, если тот близок к объёму всей памяти. В 11.1 уже не дорастал. Для vfs.zfs.arc_max=13GB:
Mem: 260K Active, 5932K Inact, 122M Laundry, 15G Wired, 844M Buf, 404M Free
ARC: 11G Total, 6502M MFU, 3255M MRU, 692K Anon, 152M Header, 923M Other
8341M Compressed, 52G Uncompressed, 6.41:1 Ratio
Основная роль - samba сервер (правда есть шара и на ufs). Также заметил, чтобы всем запущенным в пике без проблем хватало памяти, при переходе на новую FreeBSD приходилось снижать vfs.zfs.arc_max (пару раз уж точно было).

Ну, у меня это месяцами

Ну, у меня это месяцами раздаёт торренты. И «сдуваться» моё — это масштабы недель, а не часов.

Чтобы не начиналось сначала -

Чтобы не начиналось сначала - делать раз в час?
Вообще, я сейчас почитал несколько раз ~200Gb, оно быстро (за ~2 прохода) вытесняется в L2ARC, но не вижу чтобы (L1)ARC сдувался бы при этом.

Буду поглядывать, экспериментировать с этим черным ящиком маленько влом.

Есть идиотское решение —

Есть идиотское решение — запустить в юзерленде программу, которая зааллоцирует и потрогает (раз в размер страницы) столько гигов, сколько разница между wired и arc. Тут система проснётся, почистит свои кеши аллокаторов, что бы отадть память юзерленду, а как программа выйдет — увидит что у неё куча свободной памяти и arc снова вырастет. Но потом всё начнётся сначала.

Я поставил arc_max = 42G,

Я поставил arc_max = 42G, посмотрим что будет через месяцок.
На то что Arc сжимается - я не обращал внимания. Т.е. возможно что и сжимается, но я не думал что надо туда смотреть.

Вообще, выбор между 11.0 и 12.0 будет тяжелым, поскольку в 12 сеть действительно быстрее (а при реальных нагрузках кроме backup - я типично читаю из L2ARC, который вроде не съежопливается).

У меня памяти 32, ARC

У меня памяти 32, ARC анлимитед. И паттерн один: после загрузки он разрастается до примерно 28, wired при этом 29. А потом wired Навсегда остаётся 29, а ARC начинает сдуваться и сдувается до 12 а иногда и 9. Потому что память, которую он возвращает (когда эвиктит ненужное) оседает где-то в структурах аллокаторов и не аллоцируется снова, а ARC'у говорят, что память кончается и он себя поджимает.

И, повторю, это не только у меня проблема — примерно раз в месяц в списки рассылки приходит очередной страдалец, и возникает хор Me Too, но ноль реакции от тех, кто понимает в потрохах ZFS. Это длится уже больше года.

Плюс я давал ссылку на прямой, подтверждённый, но непофикшенный баг в базовой логике ARC, который есть не только у нас, а и в апстриме тоже. Есть некрасивый, костыльный, фикс, но его не коммитят молча без объяснения причин.

ГРРРРРРРРР.

Добавлю наверное до 42, из

Добавлю наверное до 42, из интересу.

Что значит впустую?

Что значит впустую?
Mem: 25M Active, 154M Inact, 41G Wired, 968M Buf, 5860M Free
ARC: 35G Total, 4273M MFU, 30G MRU, 4416K Anon, 64M Header, 1305M Other

У меня всего памяти 48, ARC-y разрешено 35, он их и берет

Ну вот после compressed и ABD

Ну вот после compressed и ABD, обрати внимание на разницу WIRED и ARC:

Mem: 73M Active, 1752M Inact, 20M Laundry, 29G Wired, 271M Free
ARC: 14G Total, 3682M MFU, 8900M MRU, 2450K Anon, 71M Header, 1285M Other
12G Compressed, 12G Uncompressed, 1.06:1 Ratio

Раньше такого не было, Wired был на пол-гига больше ARC'а (точнее — наоборот, ARC был на пол-гига меньше Wired). А теперь память уходит впустую, после изменений менеджмента ARC'а. В списках рассылки раз в месяц кто-нибудь жалуется, но пара человек, которые могли бы начать разбираться, просто отмалчиваются.

Хитрейт упал пропорциолнально

Хитрейт упал пропорциолнально. У меня у этого сервера 16 гигов было во времена 11.0, и хитрейт был больше, чем сейчас, когда гигов 32, но 11.2-STABLE. Нагрузка не изменилась ничуть.

Добавил 16 гигов памяти, блин, что бы оно не в ARC шло а просто в кэши самих аллокаторов.

И, в общем, мне проще памяти

И, в общем, мне проще памяти добить с 48 до 64, но сжатия этого - глаза бы не видели.

У меня, по всей видимости, не

У меня, по всей видимости, не столько метаданных.
Top показывал что почти все - compressed (не сохранил), но с очень хреновым ratio.

В 11.1 такого не было

Глянул в arc.c в 11.1 - точно было включено по умолчанию. Буквально на празники переходил с 11.1 на 12.0. Перед переходом всё не спеша проверял, смотрел что изменилось и всё равно через день работы нарвался на проблему. Пришлось аврально искать решение :-).

Ну вот деградация верификации

Ну вот деградация верификации бэкапов - это новость 12.0
В 11.1 такого не было (но и сеть была медленнее, но конечно быстрее этих 2-2.5 гбит/с)

включили в 12-й вроде бы?

Не уверен, но мне кажется в 11.1.

А у меня ratio в районе 1.1:1

На данном конкретном сервере данные тоже жмутся в зависимости от пользователя где-то от 1.1 до 1.5. Зато метаданные в 25 раз - вот и результат :-).

Ну да, но по-умолчанию

Ну да, но по-умолчанию включили в 12-й вроде бы?

А у меня ratio в районе 1.1:1

А у меня ratio в районе 1.1:1 т.е. смысла нету никакого, а горя много (как показалось)

Эта компрессия — вообще одна диверсия

Помню ждал когда же она появится :-). В принципе доволен. Пришлось правда чуток подкрутить. С реального рабочего сервера:
ARC: 11G Total, 6502M MFU, 3255M MRU, 692K Anon, 152M Header, 923M Other
8341M Compressed, 52G Uncompressed, 6.41:1 Ratio

FreeBSD 12

vfs.zfs.compressed_arc_enabled вроде появился где-то года два с лишним назад. И да везёт тебе с George Wilson-ом :-).

Там ради этого было много

Там ради этого было много усложнения кода в hot path, который проходится даже если enabled=0. Плюс вот это, что фактически сломало саму идею ARC и никто не чинит:

https://reviews.freebsd.org/D19094

Теоретически, lz4 быстрый же

Теоретически, lz4 быстрый же очень?

Но наверное не на Atom....

Эта компрессия — вообще одна

Эта компрессия — вообще одна диверсия, вмести с линуксоидным ADB (аллокатором) :-(

Ну да, там делается какая-то

Ну да, там делается какая-то конверсия настроек (если из 5 переключить в 2, то появляется контраст и еще там что-то, забыл).
Но любая конверсия настроек, если собственно "процессы" отличаются - не будет совершенной.

Почему смешно, так и должно

Почему смешно, это просто все в беспамятстве делается, так и должно выйти, мы это даже описывали.

Смешно, что если переключить

Смешно, что если переключить ACR в из 5 (стандарт сейчас) в 2 а потом обратно в 5, то в экспокоррекции появляется -1, в контрасте тоже не 0, и кривая становится custom хотя была linear (у меня всё по нулям в дефолте).

Да вот уже несколько дней в

Да вот уже несколько дней в поисках. Можно конечно самому написать, но это потом оптимизировать его и делать более быстрым. Возня. Не знаю, думаю, может попробовать OpenCV.

Тогда для вашей задачи оно

Тогда для вашей задачи оно еще более не предназначено.

Pages

Subscribe to comments_recent_new