Дедупликация съела 32 ГБ памяти ради 12% экономии места

MAATRIX

Дедупликация продаётся как бесплатный обед: включаете один параметр — и хранилище само находит повторяющиеся блоки данных, экономя место без всяких компромиссов. На практике компромисс есть, просто он спрятан не на диске, а в оперативной памяти. И проявляется он не в момент включения, а через недели или месяцы, когда сервер вдруг начинает требовать памяти заметно больше, чем закладывалось, а экономия места на диске при этом оказывается скромной. Разберём, откуда берётся эта плата, как её прикинуть заранее и когда дедупликация всё-таки того стоит.

Что обещает дедупликация и что она делает на самом деле

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

Важная деталь: дедупликация в большинстве систем работает на уровне блоков, а не файлов целиком. Два файла считаются дублирующими друг друга частично, если совпадают конкретные блоки, из которых они состоят, а не когда файлы идентичны побайтово как единое целое. Это делает дедупликацию мощнее простого «найти одинаковые файлы» — она ловит совпадения и внутри разных файлов, — но и требует постоянной работы на уровне отдельных блоков при каждой записи.

Механически это выглядит так: при записи нового блока система считает его хеш (обычно криптографический — SHA-256 или похожий, чтобы вероятность случайного совпадения разных данных была пренебрежимо мала) и ищет этот хеш в индексе уже известных блоков. Если хеш найден — блок не пишется повторно, увеличивается только счётчик ссылок на существующую копию. Если не найден — блок записывается как обычно, а в индекс добавляется новая запись. Логика простая. Цена скрыта в том, что индекс должен где-то храниться и быть доступен быстро.

Механизм платы: почему индекс живёт в памяти, а не на диске

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

Ключевая и часто недооцениваемая деталь: индекс растёт не пропорционально текущему объёму данных на диске, а пропорционально общему числу уникальных блоков, когда-либо через него прошедших. Если вы записали, а потом удалили большой объём данных, соответствующие записи индекса освобождаются только после фактического удаления или перезаписи блоков — до этого момента индекс уже успел вырасти до размера, отражающего пиковую, а не текущую нагрузку. Поэтому индекс — это в каком-то смысле накопленная история использования хранилища, а не снимок его нынешнего состояния.

Точный коэффициент «сколько байт памяти на одну запись индекса» зависит от конкретной реализации, размера блока и версии системы — это не универсальная константа, и приводить единую цифру как факт означало бы выдавать ориентир за измерение. Общий же принцип устойчив в любой реализации: с ростом объёма уникальных данных требования к памяти растут линейно и без потолка, привязанного к размеру самого диска. Планка, которую вы закладывали под кеш чтения и обычную работу приложений, — это отдельная величина; дедупликация добавляет к ней собственный, растущий сам по себе довесок.

Практический случай: скромная экономия ценой заметной памяти

Возьмём характерный, часто повторяющийся сценарий — не как измеренный кейс с точными цифрами, а как иллюстрацию механики, которая реально всплывает на практике. Команда разворачивает хранилище под резервные копии баз данных и образы виртуальных машин, рассчитывая на большую долю совпадающих блоков: «бэкапы же во многом похожи день ото дня, дедупликация должна дать заметный выигрыш». Дедупликацию включают на весь объём без предварительного расчёта.

Первое время всё выглядит нормально — индекс небольшой, помещается в память без проблем. По мере роста объёма уникальных данных (а бэкапы баз данных, в отличие от почти идентичных VM-шаблонов, зачастую куда менее похожи друг на друга блок в блок, чем кажется на глаз — сказываются сжатие, изменение внутренней структуры файлов между снимками, фрагментация) индекс постепенно съедает десятки гигабайт оперативной памяти, которая раньше уходила под кеш и обычные нужды сервисов. А итоговая экономия места на диске — не кратная, а в районе десяти с небольшим процентов: реального пересечения между «похожими» бэкапами оказалось заметно меньше, чем ожидалось на старте.

Именно в этом суть заголовка этой статьи: 32 ГБ и 12% — иллюстративные, а не измеренные на конкретном сервере величины, но соотношение между ними типично для сценариев, где реальная доля дублей переоценена на старте. Проблема не в том, что дедупликация «не работает» — она честно делает то, что обещает, — а в том, что решение о включении принято до расчёта, а не после. Память для индекса при этом посчитана постфактум, когда её уже пришлось докупать или урезать другие сервисы, чтобы её высвободить.

Разный потенциал дедупликации для разных типов данных

Прежде чем включать дедупликацию, стоит честно оценить, какая доля данных на конкретном хранилище действительно повторяется на уровне блоков — а этот показатель отличается для разных типов нагрузки не на проценты, а на порядки.

Где дедупликация обычно оправдана. Хранилище множества похожих образов виртуальных машин или контейнеров, построенных на одном базовом шаблоне ОС с минимальными различиями — классический случай, где доля совпадающих блоков измеряется не единицами процентов, а кратностями. То же самое — параллельные копии одной и той же базы данных для тестовых и staging-окружений, если они синхронизируются нечасто и не успевают сильно разойтись.

Где потенциал обычно скромный или отсутствует. Уникальный пользовательский контент — фотографии, видео, документы разных пользователей — почти не даёт совпадений на уровне блоков, каждый файл уникален по своей природе. Уже сжатые данные (архивы, медиафайлы в сжатых форматах) дедуплицируются плохо в принципе: сжатие меняет байтовое представление данных так, что даже минимальные различия на входе полностью меняют результат на выходе, и совпадающих блоков почти не остаётся. То же касается зашифрованных данных — шифрование по своей природе делает результат похожим на случайный шум, и одинаковый исходный блок после шифрования разными ключами или с разным IV даёт совершенно разные байты. Рабочие файлы СУБД — из-за постоянной перезаписи страниц, индексов и внутренней перестройки структуры — тоже часто дают куда меньше совпадений блок-в-блок, чем интуитивно ожидается от «наверняка там много одинакового».

Практический вывод простой: не полагайтесь на интуицию о «похожести» данных — оцените реальную структуру конкретного набора данных, который собираетесь дедуплицировать, а не общие рассуждения о классе задачи.

Экономика решения: цена памяти против цены диска

Дедупликация — это, по сути, обмен одного ресурса на другой: вы платите оперативной памятью, чтобы сэкономить дисковое пространство. Прежде чем включать её, имеет смысл явно посчитать эту сделку в деньгах, а не в абстрактных процентах.

На типичных тарифах VPS и выделенных серверов дополнительный гигабайт оперативной памяти в большинстве случаев обходится дороже, чем дополнительный гигабайт дискового пространства — это общее свойство структуры цены у большинства провайдеров, а не число, которое стоит воспринимать как точный курс обмена. Если для дедупликации нужно постоянно резервировать заметный объём памяти сверх обычных потребностей приложений, а взамен экономится сравнительно небольшая доля диска, экономика сделки может оказаться отрицательной: проще и дешевле было бы просто докупить диск нужного объёма, чем оплачивать память под индекс.

Полезно свести решение к прямому сравнению:

Стоимость(доп. RAM под индекс) vs Стоимость(сэкономленный объём диска)

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

Стоит учитывать и риск, который не сводится к деньгам напрямую: если индекс перестаёт помещаться в память целиком, производительность записи может деградировать резко и заметно, а откат обратно — отключение дедупликации — не освобождает память мгновенно, потому что уже дедуплицированные блоки остаются привязаны к записям индекса до их фактического удаления или перезаписи. Если хочется разобрать этот сценарий подробно на примере одной конкретной системы — в статье про дедупликацию в ZFS он расписан по шагам, вплоть до команд диагностики и постмортема с деградацией записи.

Как протестировать дедупликацию перед включением в проде

Единственный надёжный способ узнать, окупится ли дедупликация на конкретных данных, — протестировать её на копии реальных данных, а не на синтетическом наборе и не на предположении «наверняка похоже».

Практическая последовательность:

1. Соберите представительную выборку. Возьмите реальный срез данных того типа, который собираетесь дедуплицировать — не тестовые файлы «для примера», а копию актуальных бэкапов, образов или файлов, максимально близкую по структуре к боевой нагрузке.
2. Запустите тест в изолированном окружении. Разверните тестовый том или датасет с включённой дедупликацией на этой выборке отдельно от прода. У некоторых систем (например, у ZFS через zdb -S) есть режим симуляции, оценивающий потенциальный коэффициент дедупликации без реального включения — это дешевле по риску, чем сразу пробовать на боевых данных, но не заменяет полноценный тест на копии, если такой режим недоступен или вы не доверяете его точности для вашей версии системы.
3. Замерьте фактический коэффициент дублирования. Сравните объём данных до и после — именно измеренный, а не предполагаемый процент экономии.
4. Оцените реальный размер индекса по факту теста, а не по формуле из документации — количество уникальных блоков в выборке даёт представление о том, сколько памяти индекс потребует при аналогичной плотности дублей на полном объёме продовых данных.
5. Сравните стоимость — по схеме из предыдущего раздела — и только после этого принимайте решение включать дедупликацию в проде или нет.

Если тест на реальных данных недоступен (например, дедупликация рассматривается ещё на этапе проектирования нового хранилища, до того как данные вообще появились), разумнее отложить решение до момента, когда данные накопятся хотя бы в небольшом представительном объёме, чем включать функцию «на всякий случай» с самого начала и разбираться постфактум. Отдельно стоит заглянуть в то, как устроены хранилища в Proxmox и какой тип выбрать под конкретную задачу — там разбирается похожий по духу выбор: не какая технология звучит эффективнее на бумаге, а что реально подходит под тип данных и нагрузку.

Частые вопросы