Короткий ответ

dedup=on держит таблицу DDT в RAM (и частично на диске, но горячая часть ест память). На NAS01 это выглядит как «ZFS сожрал всю RAM»: SMB/NFS timeout, OOM, долгий import. Снимите zpool status -D tank и объём уникальных блоков. Отключение zfs set dedup=off не переписывает старые блоки: DDT живёт, пока живы дедуплицированные данные. Реальный выход — миграция на новый dataset/пул без dedup (zfs send | zfs recv) или добавление RAM по расчёту. Не «почистите кэш».

Симптомы и как отличить

Типичная картина:

  • SCALE: 128 ГБ RAM, 90+ уходит в ядро, приложения душатся;
  • dedupratio 1.05 — память едите, выигрыша нет;
  • import tank 40 минут;
  • без dedup соседний пул летает.
ВидноНе DDT
Снимки USEDSNAP огромныйснимки
Место 100%ёмкость/thin
Один процесс user-spaceутечка приложения
L2ARC диск 100% busyкэш, не таблица дедупа

Возможные причины

  1. Включили dedup «для VM», а виртуальные диски почти уникальны (ratio ~1).
  2. Мелкий recordsize, миллиарды записей DDT.
  3. Добавили данные, RAM не добавили.
  4. Дедуп на всем tank, не на одном dataset с ISO.
  5. После снимков DDT не сдувается так, как ждёт админ.

Диагностика

1. Включён ли dedup

zfs get -r dedup tank
zpool get dedupratio tank

on/verify — да. off на корне не значит off на потомках.

2. Размер DDT

zpool status -D tank

Строки DDT entries, core/disk. Чем больше entries, тем больше RAM.

Ubuntu дополнительно (осторожно, тяжёлый zdb):

sudo zdb -U /etc/zfs/zpool.cache -DD tank

На огромном пуле zdb -DD может ещё подгрузить систему — в аварии сначала status -D.

3. Память

free -h
arc_summary 2>/dev/null || cat /proc/spl/kstat/zfs/arcstats

ARC сжат DDT. Swap активность на NAS — плохо.

4. Выигрыш

dedupratio 1.1 при гигабайтах DDT — выключатель напрашивается. 2.0+ на золотом образе VM — редкий осмысленный кейс, всё равно считают RAM.

Решение

Сценарий A. Авария RAM прямо сейчас

Снизьте нагрузку SMB/scrub/replication. Не reboot-луп: каждый import снова грузит DDT. Если NAS не отвечает — консоль, остановить сервисы шаринга, оставить ZFS. Добавление RAM — самый быстрый «честный» фикс, если слоты есть.

Сценарий B. Выключить на будущее + миграция

zfs set dedup=off tank/data

Новые записи без дедупа. Старые — пока копией:

zfs snapshot tank/data@migr
zfs send -L tank/data@migr | zfs recv tank/data_nodup

Проверьте свойства recv, переключите шары на data_nodup, затем destroy старого когда checksum/сравнение ок.

Сценарий C. Dedup только на ISO dataset

Оставьте узкий dataset с редкой записью, остальное off. Не весь tank.

Сценарий D. TrueNAS UI «Dedup» галка

Та же семантика ZFS. Специальной кнопки «сжать DDT» нет.

План отключения запишите: RTO шары, место 2× на время send/recv (без сжатия выигрыша может не хватить — сначала ёмкость).

Пока не хватает RAM, не включайте ещё L2ARC «для ускорения»: он тоже ест метаданные. Сначала снизьте SMB, replication и scrub. Цель — дать DDT и ARC сосуществовать, пока не привезут DIMM или не начнёте send/recv.

Оценка перед миграцией: zfs list по used и logicalused плюс свободное на приёмнике. Если logicalused почти равен used при dedupratio 1.05, recv почти не сожмётся — нужно почти столько же места. Без этого плана destroy старого dataset не сделаете.

На SCALE не путайте Deduplication в UI с compression. Выключение сжатия не трогает DDT. В паспорте NAS01 должно быть: dedup on или off, дата, кто включил.

Как проверить, что проблема устранена

free и отзывчивость UI. zpool status -D entries падают после удаления старых дедуп-данных, не сразу после dedup=off. dedupratio на новых dataset 1.00. Import после ребута за разумное время. SMB latency в норме.

Если не помогло

  • dedup=off, DDT тот же: старые блоки на месте, нужна миграция/destroy старого.
  • OOM на recv: стримите с меньшим параллелизмом, не крутите ещё и scrub.
  • Special vdev/dedup vdev (новые OpenZFS) — не включайте, не прочитав версию; не совет «добавить special» в аварии.
  • Контейнеры на том же NAS: user memory vs DDT, смотрите slabtop/arcstats.

Профилактика

  • По умолчанию dedup=off.
  • Считать RAM до включения: unique TB × оценка DDT.
  • Не включать на блочных zvol SQL.
  • Compression lz4 даёт часть выигрыша без DDT.
  • Мониторинг zpool status -D и ARC.
  • Документировать, кто включил и зачем.

На стенде перед включением dedup в проде прогоните оценку: копия типичного dataset, dedup=on, замер status -D и RSS. Если ratio < 1.2 при заметном DDT — в прод не тащите. Большинство файловых шаров и SQL zvol в этот критерий не проходят.

Когда миграция send/recv идёт сутками, режьте на dataset, не весь tank одним пайпом. Проверяйте checksum приёмника (zfs diff / сравнительный zstreamdump по политике), затем переключайте шару. Откат — вернуть SMB path на старый dataset, не destroy посреди потока.

FAQ

dedup=verify безопаснее?

Проверяет checksum при дедупе, ещё дороже CPU, DDT тот же класс проблемы.

Можно ли освободить RAM echo 3 > drop_caches?

Не лечение DDT. ARC живёт в SPL, не в page cache пользователя.

TrueNAS «dedup tables on disk» спасает?

Снижает часть давления, не делает 32 ГБ достаточными для 50 ТБ unique с мелким блоком.

send/recv сохранит дедуп?

По умолчанию на приёмнике свойства задаёте вы. Явно dedup=off на recv.

Это из-за snapshots?

Снимки держат старые блоки, включая дедуплицированные. Retention помогает косвенно, но не заменяет выключение.