Когда СУБД упирается в память, одинаковое слово «расширить» может означать три разные задачи. Сервер способен плотнее использовать уже установленную RAM за счёт сжатия, сократить обращения к обычному swap или добавить физическую ёмкость NVMe под управлением модели. Эти варианты расходуют разные ресурсы.
zram, zswap и предиктивная память не образуют рейтинг от худшего к лучшему. zram создаёт сжатое блочное устройство в оперативной памяти. zswap удерживает swap-страницы в сжатом RAM-кэше. Предиктивный слой управляет тем, какие физические страницы находятся в DRAM и на NVMe.
Для CTO главный вопрос звучит не «какая технология быстрее», а «за какой ресурс платит конфигурация и какую сервисную цель она достигает». Сжатие обменивает процессорное время на более плотное использование RAM. NVMe добавляет отдельную ёмкость, но вводит I/O. Результат сравнивается по p99, SLO и стоимости обслуженной нагрузки.
zram увеличивает плотность внутри RAM
Документация Linux определяет zram как блочное устройство, основанное на оперативной памяти. Данные, записанные на него, сжимаются и хранятся в самой RAM. Такое устройство часто используют как swap, но оно также может служить для временных данных и других сценариев блочного доступа.
Источник ёмкости здесь — коэффициент сжатия. Если страницы хорошо сжимаются, их логический объём заметно превышает физически занятый. Если данные уже сжаты, зашифрованы или близки к случайным, выигрыш будет другим. Универсальная пропорция для СУБД из механизма не следует.
Цена тоже находится внутри сервера. Процессор сжимает страницы при записи и распаковывает при чтении. Оперативная память хранит сжатые данные, метаданные и накладные расходы распределителя. Поэтому заявленный размер устройства не равен фактически высвобождённой RAM.
Linux экспортирует отдельные показатели исходного размера, сжатого объёма и всей памяти, занятой zram. Для платформенной команды это полезное разделение: она видит не виртуальную ёмкость как обещание, а фактический обмен RAM и CPU на конкретной нагрузке.
zswap уменьшает часть swap I/O
zswap занимает другое место в пути памяти. Документация Linux называет его лёгким сжатым кэшем для swap-страниц. Когда страницу собираются вывести в swap, zswap пытается сжать её и сохранить в динамическом пуле оперативной памяти.
Если страница вскоре понадобится снова, её можно получить из сжатого пула без чтения с основного swap-устройства. При заполнении пула часть данных покидает его и записывается на backing swap. Поэтому zswap не является новым блочным устройством общего назначения: он оптимизирует конкретный путь swap.
Ресурсный обмен понятен. Компрессия расходует CPU, а пул занимает RAM, зато часть обращений к более медленному устройству не происходит. Ценность зависит от сжимаемости страниц, частоты повторных обращений и цены I/O именно на этом сервере.
Эта задача отличается от расширения физического уровня. zswap повышает эффективность существующего пути, но его ёмкость остаётся связанной с выделенным RAM-пулом и backing swap. Сервисный эффект измеряется не размером пула, а тем, как изменились задержка, I/O и полезная работа СУБД.
Предиктивная память управляет DRAM и NVMe
Предиктивный слой использует NVMe как отдельный физический уровень ёмкости. Он не получает пространство за счёт упаковки байтов внутри DRAM. Его задача — определить, каким страницам сейчас нужен быстрый уровень и какие могут находиться на NVMe до следующего возврата.
В gigaRAM предиктивная математическая модель по реальным обращениям решает, что, куда и когда перемещать или возвращать между DRAM и NVMe. Решения принимаются ниже приложения и не требуют ручных правил для таблиц, ключей или страниц. DRAM и NVMe становятся управляемой иерархией.
Сжатие отвечает на вопрос «сколько байтов поместится в RAM после упаковки». Предиктивное размещение отвечает на вопрос «какому физическому уровню поручить страницу в текущей фазе». Хорошо сжимаемая страница может быть критичной для p99, а плохо сжимаемая — обращаться редко. Эти признаки не заменяют друг друга.
Подробное отличие предиктивного управления от обычного swap как реактивного механизма раскрывается отдельно. Здесь важна ресурсная граница: дополнительную ёмкость предоставляет NVMe, а модель связывает её с DRAM по поведению реальной нагрузки.
Три механизма отвечают на разные вопросы
Сравнение удобно свести к одному управленческому экрану. Он не выбирает победителя заранее, а показывает, какой бюджет и какой результат надо измерять.
| Механизм | Основная цель | Какой ресурс расходует | Управленческий вопрос |
|---|---|---|---|
| zram | Плотнее разместить данные в существующей RAM | CPU на сжатие и RAM на сжатый объём | Достаточен ли выигрыш сжатия при целевом p99? |
| zswap | Сократить часть обращений к backing swap | CPU и RAM-пул, при необходимости I/O swap | Сколько полезного I/O удалось избежать в критичную фазу? |
| Предиктивная память DRAM+NVMe | Добавить управляемый физический уровень ёмкости | NVMe, I/O и вычисление решений размещения | Какой объём нагрузки обслуживается внутри SLO при данной конфигурации? |
Таблица также показывает риск смешения. Если проблема — нехватка физической ёмкости, один коэффициент сжатия не описывает весь вариант. Если CPU уже насыщен, дополнительная компрессия конкурирует с запросами. Если NVMe занят вводом-выводом СУБД, новый страничный поток рассматривается вместе с этим контуром.
Сочетание механизмов не следует предполагать автоматически. У них могут пересекаться процессорные, RAM- и I/O-бюджеты. Архитектура начинается с одной диагностированной цели, после чего команда измеряет итог на сервисе, а не складывает виртуальные гигабайты из разных механизмов.
Владельцы связывают ресурс с p99
Платформенная команда владеет конфигурацией RAM, CPU, NVMe и системной наблюдаемостью. DBA знает рабочие фазы, I/O базы и критичные запросы. Владелец сервиса задаёт SLO и цену задержки. Только вместе они могут решить, какой ресурс действительно ограничивает рост.
Linux PSI помогает перевести давление CPU, памяти и ввода-вывода в потерянное время выполнения. Материал о PSI и давлении памяти показывает, почему один высокий счётчик не равен бизнес-проблеме: важна связь с периодами, когда задачи перестают выполнять полезную работу.
Для zram команда сопоставляет сжатый объём с загрузкой CPU и p99. Для zswap — попадания в сжатый пул, backing I/O и задержку. Для предиктивной ёмкости — размещение страниц, I/O NVMe, объём DRAM и число операций внутри SLO. Метрики разные, итоговая единица одна.
Сигнал инвестировать в дополнительную ёмкость возникает, когда сжатие уже является осознанным CPU-компромиссом, рабочий набор продолжает расти, а линейная покупка DRAM повышает стоимость узла. Тогда DRAM+NVMe рассматривается как отдельная архитектура, а не как ещё один параметр swap.
Стоимость определяет обслуженная нагрузка
Цена гигабайта не соединяет три механизма в корректное сравнение. У zram и zswap часть стоимости выражена в процессорном времени и занятой RAM. У предиктивной памяти появляются NVMe и I/O. У всех вариантов есть влияние на хвост задержки и операционную работу.
Для действующего сервера бизнес сравнивает, сколько запросов или транзакций остаётся в пределах SLO при той же аппаратной базе. Для новой конфигурации — сколько полезной нагрузки обслуживает узел за выбранный бюджет. Такой подход не требует универсального процента замещения.
gigaRAM в этой системе координат представляет управление физической ёмкостью, а не сжатую память или замену механизмов Linux. zram и zswap сохраняют собственные роли. Выбор становится яснее, когда каждый инструмент оценивается по своей цели и общему результату сервиса.
Итоговая архитектура может использовать DRAM, CPU и NVMe в разных пропорциях, но последовательность остаётся одной. Сначала формулируется ограничение, затем определяется ресурсный обмен, после чего p99 и SLO подтверждают бизнес-эффект. Так память СУБД масштабируется без смешения технологий с разными задачами.
Источники. Документация Linux zram определяет сжатое блочное устройство в RAM и показатели исходного, сжатого и фактически занятого объёма. Документация Linux zswap описывает сжатый кэш swap-страниц и обмен процессорного времени на сокращение swap I/O.
Документация Linux DAMON подтверждает класс наблюдения за доступами. Meta Engineering: Transparent Memory Offloading используется как первичный отраслевой пример автоматического управления неоднородной памятью; его реализация и результаты на другой продукт не переносились.
Технология gigaRAM — единственная коммерческая ссылка и источник описания предиктивного размещения страниц между DRAM и NVMe.