ZFS: vfs.zfs.compressed_arc_enabled=0

У одного моего друга есть файловый сервер под FreeBSD 12 :)

И вдруг я он заметил, что скорость верификации бэкапов упала с 2-2.5 Gbit/s (это ограничение Acronis Backup, быстрее оно не делает) до меньше чем одного гигабита, 600-800Mbit/sec.

Ну вот vfs.zfs.compressed_arc_enabled=0 вроде как помогло. Процессор то медленный у меня него.

Продолжаем наблюдения.

Comments

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

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

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

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

https://reviews.freebsd.org/D19094

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

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

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

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

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

Если бы всё как из коробки, то ratio был бы до 1.2. Это после перераспределения в арке лимитов для meta и data и изменения порядка вытеснения из арка (из коробки недоступно). Можно сказать это субъективное видение настройки арка для самба сервера, а мои попытки просто наращивать объём доступной памяти при дефолтовых настройках имели слабый эффект.

Ну вот после 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'а. В списках рассылки раз в месяц кто-нибудь жалуется, но пара человек, которые могли бы начать разбираться, просто отмалчиваются.

Что значит впустую?
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, он их и берет

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

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

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

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

ГРРРРРРРРР.

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

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

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

Чтобы не начиналось сначала - делать раз в час?
Вообще, я сейчас почитал несколько раз ~200Gb, оно быстро (за ~2 прохода) вытесняется в L2ARC, но не вижу чтобы (L1)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 (пару раз уж точно было).

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

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

Аптайм всего 10 дней после переезда на 12, поэтому мне нечего пока про что-то говорить. Посмотрим. arc_max если не задан при инициализации устанавливался на гигабайт меньше доступной памяти. С такой установкой в период пиковых нагрузок стали возникать проблемы, поэтому пришлось явно уменьшать. Заодно не стало постоянной войны за память.

Да, arc_max дефолтовый. Но я хочу сказать, что с началом вот этих проблем "ARC <= 1/2 Wired" война за память у меня кончилась. Лучше бы была война за память, честное слово.

У ZoL по умолчанию в отличии от FreeBSD arc_max устанавливается в 1/2 от доступной памяти :-).

facepalm.jpg

Ну вот я не выдержал, заалоцировал в юзерлендле 20 гигабайт (ARC ужался до 7 гигов, Wired стал 7.5 гигов) и подождал после этого буквально час и вот результат

Mem: 33M Active, 185M Inact, 55M Laundry, 30G Wired, 1200M Free
ARC: 26G Total, 3008M MFU, 21G MRU, 2511K Anon, 39M Header, 1299M Other
23G Compressed, 24G Uncompressed, 1.03:1 Ratio

Но скоро опять начнёт ARC сдуваться. И как так жить?!

У меня оно как-то не так работает:
за ночь ARC сдулся до 39G, Wired - 45 (было вчера, после всяких экспериментов с тем что попадает в ARC: 42/45)
Т.е. дельта стала 6Gb.
Аллоцировал с юзерленда 40Gb. Результат ARC: 5.2G, Wired: 10G (чуть меньше). Дельта - соотв. 5G,

Т.е. аллокация + освобождение - не работает так как ты пишешь.

FreeBSD у меня свежая stable, пересобрал уж до кучи: FreeBSD 12.0-STABLE r347380 GENERIC

Продолжаю наблюдение. В принципе, исходя из паттернов использования, насильный evict из ARC (подозреваю что частично - в L2) - это не самый плохой в моем случае вариант, т.к. всякий там утренний бэкап - он будет новый (а всякие MFU-файлы c которыми часто работаю, я планирую что в L2 уедут).

UPD: но да, ARC 5.2, Free: 37, т.е. если никто память жрать не будет, то ARC подрастет до своих 42..... Верифицирую ка я бэкапчик например.

Подросло до 39.

Продолжаем наблюдения....

У нас, очевидно, очень разный паттерн доступа и ожидать одинакового поведения кешей было бы странною

Я сравниваю то, что вижу сейчас с тем, что было в 11.0, и то, что сейчас, выглядит гораздо хуже. Могу коротко описать в одном сообщении:

Загрузка → Наращивание ARC до всей свободной памяти, раздел Wired опережает ARC на 0.5-1G → Wired больше никогда не меняется (так и остаётся в 90% памяти) а ARC сдувается по ~ 1GB/день до 5-7GB и стабилизируется в таком виде.

Это при 32GB памяти.

В результате через две недели после загрузки под постоянной и одинаковой нагрузкой (торренты) — свободной памяти ноль (это само по себе ничем не плохо), но кэш — 5-7GB а остальная память занята неизвестно чем.

Я оставлю на недельку(другую), посмотрю что там с ARC.
У меня на этом сервере
а) чистый файлер, причем записей заметно больше, чем чтений (потому что бэкапы, в районе терабайта в неделю).
б) чуть-чуть rsync с удаленных серверов (тоже бэкапы)
Торренты тоже, но это utorrent на моей виндовой машине, а файлы - на этом файлере. И чуть-чуть, я раздаю только когда сам что-то качаю, а качаю я очень мало.

Пока писал - ARC подрос до 40G, т.е. вот тенденции к его угасанию. я не вижу.

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

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

Если имеется ввиду хитрейт при включенной компрессии, то он нещадно врал, так как считал все запросы BP embedded к арку как промах. Перестал смотреть, поэтому не знаю поправили ли.

Вспомнил, я ж его себе фиксил и вывел для контроля счётчик bpe. Установил zfs-stats.
ARC Efficiency: 94.87m
Cache Hit Ratio: 97.69% 92.67m
Cache Miss Ratio: 2.31% 2.20m
Actual Hit Ratio: 97.62% 92.61m
Смотрим count_bpe: 7486974. Получается 92.67 - 7.45 = 85,22 или 89,82%. Обманывает не много не мало на 7,87%.

А PR на это есть? Это же тоже очень серьёзный баг.

Можно подробностей?

Я бы сказал недосмотр при формировании статистики. Давненько это было, наверно при переходе с 10 на 11. Тоже тогда заметил, что ухудшился хитрейт. Помню простые тесты говорили, что статистика врёт. Полез смотреть :-). Создатель bp embedded хотел видимо сделать всё "элегантно" и оставить путь прохождения запроса почти без изменений. В начале arc_read сразу проверить на bp embedded и если да, то с минимальными изменениями проскочить логику arc-а, сформировать zio и уже в дальнейшем извлечь из bp данные, заодно не париться с обратным ходом данных. Но недосмотрел или не проверял как поведёт себя статистика, а в этой ветке ставится прохах (формирование zio это уже обращение к диску). В принципе ничего страшного, а я не любитель вживую общаться по техническим вопросам на английском :-). К тому же потом видел (по моему на freebsd-fs), что тоже были недовольные статистикой и кто-то в комментариях так же видел лажу с bp embeded.

Что такое bp embedded?

А, ну тогда это моей статистики точно не касается, у меня там нет ничего сжимаемого и ничего мелкого.

Вам это только кажется ;-). В основном так жмутся только метаданные, а они жмутся всегда и независимо от установок пользователя.

Много ли у меня в кэше метаданных при том, что 95% нагрузки на сервер — 50 активных торрент-раздач, где нет файлов меньше 500 мегабайт? Т.е. 95% ARC'а — это данные условно 30-50 файлов которые сейчас активно раздаются.

При чём здесь размер файла? На том сервере с которого я показывал статистику тоже нет мелких файлов. Сидят операторы с дизайнерами и ежедневно ворочают приходящие большие файлы для цифровой печати. Сжимаются не файлы, а блоки. zfs это дерево и данные находятся в его листьях (на самом нижнем уровне), а чтобы получить к ним доступ нужно пройти все блоки по пути вниз.

Сколько метаданных у 100 файлов по сравнению с 20 гигабайтами самих файлов?

# zfs-stats -E

------------------------------------------------------------------------
ZFS Subsystem Report Sun May 12 19:27:24 2019
------------------------------------------------------------------------

ARC Efficiency: 6.62b
Cache Hit Ratio: 95.55% 6.33b
Cache Miss Ratio: 4.45% 294.58m
Actual Hit Ratio: 95.24% 6.31b

Data Demand Efficiency: 95.65% 2.19b
Data Prefetch Efficiency: 16.64% 144.26m

CACHE HITS BY CACHE LIST:
Most Recently Used: 16.17% 1.02b
Most Frequently Used: 83.50% 5.28b
Most Recently Used Ghost: 0.09% 5.71m
Most Frequently Used Ghost: 0.32% 20.43m

CACHE HITS BY DATA TYPE:
Demand Data: 33.13% 2.10b
Prefetch Data: 0.38% 24.01m
Demand Metadata: 66.27% 4.19b
Prefetch Metadata: 0.22% 14.16m

CACHE MISSES BY DATA TYPE:
Demand Data: 32.39% 95.41m
Prefetch Data: 40.82% 120.25m
Demand Metadata: 25.81% 76.04m
Prefetch Metadata: 0.98% 2.87m

------------------------------------------------------------------------

#

Ваш arc получил по данным 2.10b + 24.01m + 95.41m + 120.25m запросов, а по метаданным 4.19b + 14.16m + 76.04m + 2.87m запросов. Получается в два раза больше по метаданным. Так причём здесь размер файлов?

На размеры запросов домножьте.

Меня волнует трансфер с блинов а не штуки, конечно же.

А как это влияет на хитрейт arc-а о котором Вы говорили?

IOPSы тоже ж волнуют?

По умолчанию сейчас indirect block pointers 128k. Любой промах в arc-е влечёт за собой обращение к дискам. indirect block pointers по умолчанию имеет по 2-3 разнесённые копии. Если во время чтения будет выбран далекостоящий, то получим ещё и дополнительное перемещение головок. Соотношение запросов 2:1 (довольно малое соотношение, наверно преобладает recordsize=1M, у меня соотношение значительно больше, да и статистика показывает что arc хорошо справляется с данным патерном) всё равно говорит, что желательно чтобы как можно больше метаданных читалось из arc-а (в идеале все :-)). Например для самба сервера, если клиенты имеют на своей стороне много оперативной памяти, то лучше не увлекаться кешированием данных с двух сторон, а больше внимания уделить кешированию метаданных. О которых клиент ничего не знает и дисковое обращение к которым снижает время отклика.

увеличивает :-)

Всю мою метадату можно прочесть на старте сервера в память по хорошему. Там немного по отношению к объёмы самой даты.

Когда-то я пытался это делать. Хотел проверить идею и узнать какой объем у метадаты на реальном сервере. Сейчас уже точно не помню и могу ошибаться. Где-то у миллиона файлов (каталогов не считал, но много, общий объём был около 4TB) помнится видел 9GB сжатых (сжатие было до 25 раз). Не уверен, что мне удалось тогда прочитать/удержать всю метадату и наверняка в каждом конкретном случае будут свои результаты. Удержание оказалось самой большой проблемой и из коробки её не решить (по крайней мере мне не удалось и пришлось лезть внутрь).
У Вас же очень хорошая статистика (даже если чуть и подвирает) или хотите ещё лучше :-) ?

Ну, было 98.9% когда-то. В 11.0 :-)

По поводу "здутия" и Вашей статистики мне подумалось, а будет ли увеличиваться arc после сдутия, если прочитать в null/zero какой-то объём гарантированно ранее не читаемый?

А давайте проверим! Лёгкий же эксперимент. Вот сейчас:

Mem: 30M Active, 380M Inact, 64M Laundry, 30G Wired, 445M Free
ARC: 13G Total, 4305M MFU, 7933M MRU, 2180K Anon, 53M Header, 1143M Other
11G Compressed, 12G Uncompressed, 1.06:1 Ratio

Читаем файл на G который не в торрентах:

# dd if=Paris-Roubaix\ 2016\ \[FULL\ RACE]_720.mp4 of=/dev/null bs=128k
92952+1 records in
92952+1 records out
12183471924 bytes transferred in 21.152020 secs (575995657 bytes/sec)
#

Смотрим в top:

Mem: 28M Active, 380M Inact, 67M Laundry, 30G Wired, 441M Free
ARC: 13G Total, 4288M MFU, 7956M MRU, 2108K Anon, 54M Header, 1142M Other
11G Compressed, 12G Uncompressed, 1.05:1 Ratio

читаем ещё раз:

# dd if=Paris-Roubaix\ 2016\ \[FULL\ RACE]_720.mp4 of=/dev/null bs=128k
92952+1 records in
92952+1 records out
12183471924 bytes transferred in 19.810496 secs (615000861 bytes/sec)
#

И снова в top:

Mem: 28M Active, 380M Inact, 66M Laundry, 30G Wired, 441M Free
ARC: 13G Total, 4290M MFU, 7965M MRU, 2784K Anon, 54M Header, 1142M Other
11G Compressed, 12G Uncompressed, 1.05:1 Ratio

Не-а, нифига.

Покажите zfs-stats -E

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

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

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

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

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

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

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

У меня нет подробностей. Отключил (с перезагрузкой) - деградация чтения исчезла.

Но, возможно, она потом появится, через месяц-другой.

У тебя дофига подробностей — какой процессор, сколько дисков и какие, сколько памяти, какой софт и какой объём данных как обрабатывает (хотя бы примерный паттерн доступа).

Т.е. вообще-то ты можешь назвать достаточно подробностей, что бы люди могли собрать стенд и попытаться повторить, если у них на то будет желание.

Гм, а "люди жаждут подробностей" - где-то в фоне, я на гитхабе этого не вижу?

Ну блин
1) Я не могу открыть issue на ZOL - потому что у меня FreeBSD
2) Я, на самом деле, не на 100% уверен что меня спасло отключение компрессии - поскольку я же перезагрузился, т.е. может быть там какое еще issue.
Это будет понятно через месяц.

Если ты не следишь — из-за фактической стагнации Illumos / OpenZFS FreeBSD собирается сделать апстримом своего кода ZFS именно ZFSonLinux. И если не поднимать шум сейчас, а просто молча включать опцию и успокаиваться, то через пол-года опции просто не будет.

Так что воевать с пионерами из ZoL надо сейчас. Или попрощаться с ZFS как мы его знали :-(

Ну, гм, ZFS который мы знали - тоже, как мы видим, не очень.
А в ZOL есть хотя бы живые люди.

Там Слава написал мой E-mail, если вдруг кому интересно из там - напишут.

Да меня всё эта ситуация очень печалит, да :-(

Даже для БСД оно - падчерица. А для Линукса и вообще двоюродная!

БСД у меня вообще не прижилось (хотя zfs была основным поводом).
Линукс кое где прижился, но ZoL рассматривался уже как неочевидная опция.

Несколько раз пытался себя заставить, но чувство самосохранения всегда побеждало (не в пример жабе).
И вот читаю я это сегодня, и чувство самосохранения удовлетворённо кивает.

ИМХО, надо было давным давно написать почти с нуля нативный аналог.

Это было мнение "домохозяйки"

В переписке про compressed arc, от Алана Джуда, который как раз может иметь большой вес в решении таких вопросов:

> I am not sure we want to maintain that extra code complexity just to
> support people running ZFS on Atom CPUs. If you actually have such a use
> case, please provide the details, but if your only reference to such a
> use case is one single paragraph post in russian on a random blog, it
> won't have as much weight, since it lacks all of the detail required to
> actually determine what the bottleneck is.

Как я и говорил — нужны точные подробности. Видимо, сами они тебе писать не будут (и я могу их понять, если честно).

Ну и я не буду. Потому что у меня нет issue ZoL

Это больше не ZoL, это OpenZFS теперь, и он будет в FreeBSD через пол-года. А тогда будет поздно.

Я правда не понимаю, в чём проблема.

Ну, ок. Ну то есть я не вижу как бы я мог создать issue на то, чем не пользуюсь. Но я уж как минимум напишу что это не вполне low end CPU

Давай заведём issue во FreeBSD (в багзилле) и просто я дам ссылку там на него.
Это будет может даже правильней.

И, главное, дам ссылку Алану Джуду, который один из рулителей и идеологов OpenZFS и при этом во FreeBSD, а не где-то ещё.

Блин. Ну я же сам - разработчик и понимаю как писать issue.

issue должна быть repeatable. А пока я имею "у меня тут в подполе застучало, я сделал вот так, продолжаю наблюдения".

https://github.com/zfsonlinux/zfs/issues/7896#issuecomment-491919238

Если оно повторится (с выключенной компрессией) - одна история. Не повторится - другая.

Спасибо в любом случае!

Make ZFS on FreeBSD great again!

Ну, гм.

Я, надо сказать, разнеся файлер и "остальной сервер" - всерьез подумываю а не посмотреть ли на Windows Server в качестве файлера.

Когда изведу дома совсем старые макоси (которые не умеют тайм машину на SMB) - задумаюсь еще серьезнее.

(я понимаю, ты получил это от гитхаба, но для протокола)

issue похоже repeatable: просто при повторном пере-чтении 32GB файлов (влезают в ARC) - я вижу ~460MB/sec. А не пару гигабайт, как ожидал бы.

Надо заводить freebsd issue. Ну то есть я завтра обновлюсь до 12-stable свежей и повторю еще раз-другой.

Спасибо тебе огромное.

А может и нет, хер пойми, может это датасет такой неудачный медленный, ну либо bsdtar много не умеет.

Буду смотреть как бы почитать
а) реально много файлов (а не один большой тестовый)
б) ну и с вменяемой скоростью

Будет общая code base для всех систем. И она живёт вот в этом репозитории, который исторически называется ZoL.

Раньше такая общая codebase жила в Illumos'е, но теперь — здесь.

Для Linux, для BSD, для MacOS X, для Windows (да, для Windows) — для всех.

Ну хорошо, у тебя нет проблем с ZoL, но у тебя есть явно паталогичский случай с FreeBSD ZFS, который достоин что бы быть багрепортом. Давай заведём багрепорт во FreeBSD'шной багзилле.

(и зачем я в эту политику ввязался, вечно хочешь как лучша, а....)

Нашёл подходящую линейку с временным бекапом: i5 CPU 760 @ 2.80GHz, 16GB, FreeBSD 12.0, zfs дефолтный.

vfs.zfs.arc_max: 15614353408

data/admin@test - 179638 файлов, 45302 папки.

zfs send data/admin@test | pv -i 10 > /dev/null
486GiB 0:26:17 [ 315MiB/s]

Mem: 152K Active, 2144K Inact, 15M Laundry, 15G Wired, 108M Buf, 367M Free
ARC: 14G Total, 7020M MFU, 6993M MRU, 32K Anon, 78M Header, 395K Other
14G Compressed, 23G Uncompressed, 1.65:1 Ratio

sysctl vfs.zfs.arc_max=13958643712

Mem: 200K Active, 2268K Inact, 15M Laundry, 15G Wired, 108M Buf, 366M Free
ARC: 13G Total, 6892M MFU, 6341M MRU, 32K Anon, 75M Header, 395K Other
13G Compressed, 22G Uncompressed, 1.67:1 Ratio

sysctl vfs.zfs.arc_max=12884901888

Mem: 176K Active, 2228K Inact, 15M Laundry, 15G Wired, 108M Buf, 365M Free
ARC: 12G Total, 6381M MFU, 5832M MRU, 32K Anon, 70M Header, 395K Other
12G Compressed, 20G Uncompressed, 1.70:1 Ratio

Данные из ARC-а вытеснились, а Wired и Free не изменились.
Возвращаю назад arc_max.

sysctl vfs.zfs.arc_max=15614353408

Mem: 200K Active, 2252K Inact, 15M Laundry, 15G Wired, 108M Buf, 366M Free
ARC: 12G Total, 6381M MFU, 5832M MRU, 32K Anon, 70M Header, 395K Other
12G Compressed, 20G Uncompressed, 1.70:1 Ratio

zfs send data/admin@test | pv -i 10 > /dev/null
486GiB 0:25:12 [ 329MiB/s]

Mem: 272K Active, 316K Inact, 16M Laundry, 15G Wired, 108M Buf, 439M Free
ARC: 14G Total, 7210M MFU, 6645M MRU, 32K Anon, 78M Header, 395K Other
14G Compressed, 23G Uncompressed, 1.66:1 Ratio

ARC в начале чтения сразу вернулся к 14G. Пока непонятно, что это даёт :-).

Заодно проверю, как изменится время чтения на данном процессоре при compressed_arc_enabled=0.
Перезагружаюсь.

vfs.zfs.compressed_arc_enabled: 0
vfs.zfs.arc_max: 15614353408

zfs send data/admin@test | pv -i 10 > /dev/null
486GiB 0:25:56 [ 320MiB/s]

Mem: 280K Active, 2652K Inact, 15M Laundry, 15G Wired, 35M Buf, 656M Free
ARC: 14G Total, 6715M MFU, 7607M MRU, 32K Anon, 61M Header, 448K Other

Можно сказать не изменилось. Датасет правда с включённым lz4 и может поэтому.