++ включал на ноде с 4ТБ хранилища и 64ГБ памяти, из них свободно было около 20 - съело и начало свопить

Да, обычно активно кэш используется в небольшой части, для среднегабаритного сервера со 128 ГиБ RAM  16 ГиБ ZFS ARC кэша должно хватать.

Но есть лайфхак, я например при виртуалках делаю как: не ограничиваю кэш, т.е. оставляю 50% и пусть занимает свободную память, есть, она лучше пусть в кэше будет, чем просто свистеть.
В случае, если нужно запустить новую виртуалку, я предварительно руками тротлю arc_size_max:
echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max
(уточню, это для Linux команда при использовании ZFS on Linux )

Добавление виртуалок на продакшн ситуация у нас не очень частая, потому можем себе позволить

Отключи свою автозамену, она творит херню с текстом

О чем речь?

128 ГиБ RAM

Гбит

Написано ГиБ = гибибайт, 1024 мибибайт

Угу, ГОСТ IEC 60027-2-2015 Обозначения буквенные, применяемые в электротехнике. Часть 2. Электросвязь и электроника

ну вычислять требования очень просто - до 320байт на КАЖДЫЙ блок данных (размер блока - recordsize) в таблице DDT. Точный размер зависит от конкретной реализации, были шаги в сторону уменьшения.

тогда стоит писать не в utf8, а единицами и нулями, для адекватного понимания

Кому понятнее единицами и нулями?

Ваша претензия не по существу, написанное мной не является ошибкой, так как память RAM измеряется единицами такими, это корректно. Как раз запись вида ГБ может восприниматься двусмысленно, так как в обиходе её используют для обозначения как гигабайт (например, на дисках жёстких там конкретно гига и терабайты пишут - т.е. степени 10, 1 ГБ = 1000 МБ) так и гибибайт.

Признаю, что обычно из контекста понятно о чем речь, но я предпочитаю по возможности не плодить двусмысленность. Так когда я говорю 16 ГиБ под кэш, я имею ввиду 17179869184 байт, что и использую в приведенном примере:
echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max
(уточню, это для Linux команда при использовании ZoL)

Согласен, оценку предела таблицы DDT можно посчитать, и заложить в проект, но... возникает простой критерий эффективности, будет ли оправдана по факту покупка отдельно памяти под хранение таблицы DDT (дедубликации) экономии места полученного от работы механизма дедубликации.

Ответ математический - нет, в подавляющем большинстве случаев (не сильно совру если скажу 99%). Дешевле купить диски большего размера по цене, чем использовать для экономии дискового пространства RAM.
Только в специальных случаях и видах данных будет достигаться большая эффективность и можно будет сэкономить.

Так ограничивать память надо, отведённую под ZFS

options zfs zfs_arc_max=34359738368 в моём кейсе, например, но можно и меньше

Выше прочитайте, память занятая DDT - занята всегда, т.е. её по факту нет, а значит вы отрезали кусок памяти RAM для экономии сколько-то ГБ диска. Профит будет только в специальной ситуации, т.е. его нужно доказать. А значит включать дедубликацию в zfs можно только тогда, когда доказана её реальная эффективность, иначе (в 99% случаев) лучше включить lz4 сжатие (в принципе можно почти всегда), которое экономит дисковое пространство практически бесплатно

Это лимит в 32Гб, для сервера с 256Гб. Можно меньше, я просто перестраховывался, IOPS больше волнует пока

Free RAM = wasted RAM, и просадки по дисковой подсистеме меня больше волнуют, чем 12,5% оперативки, пущенной в дело.

ну кстати она не "занята всегда". Она успешно вытесняется из кеша. Другой вопрос, что никто этого не захочет :)

Лучше пусть ZFS ARC её занимает

"не захочет" - это очень мягко говоря, в реальности у вас по сути будет жесточайший тупняк (latency) при попытке записи, оно будет поднимать с диска! таблицу при каждой операции записи!!!

Потому в логике zfs DDT вытесняется в крайнюю очередь