Сервер может показывать почти полностью занятую RAM и при этом регулярно обращаться лишь к части страниц. Остальной объём остаётся выделенным приложению или файловому кэшу, но в текущей фазе редко участвует в полезной работе. Такой объём называют cold memory — менее активной памятью. Снимок «used» не отделяет её от страниц, защищающих задержку СУБД.

Риск возникает, когда по проценту использования закупают DRAM, добавляют узлы или ограничивают плотность, не зная активного рабочего набора. Нельзя и считать давно не затронутую страницу постоянной cold memory. Страница, не востребованная утром, может оказаться критичной во время отчёта, восстановления или пика.

Занятая RAM не равна активному рабочему набору

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

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

Резидентная память, активный набор и размер базы имеют разные границы. Размер базы описывает хранение, резидентная память — то, что сейчас находится в RAM, а рабочий набор — повторно востребованные страницы. Как эти величины превращаются в закупочный объём, разобрано отдельно в материале про бюджет RAM для СУБД по рабочему набору. Здесь задача диагностическая: понять, есть ли устойчивый разрыв между занятостью и активностью.

Cold memory меняется вместе с фазами

У транзакционной СУБД рабочий день может начинаться с прогрева часто читаемых таблиц, продолжаться короткими запросами и заканчиваться отчётами. Фоновые операции, резервное копирование, обслуживание индексов и восстановление реплики добавляют собственные страницы. В каждой фазе холодным оказывается разный участок памяти. Постоянного списка «ненужных» страниц не возникает.

Отраслевой пример Meta TMO показывает, почему наблюдение нельзя свести к одному проценту: доля страниц без недавних обращений заметно различалась между приложениями. Эти данные относятся к инфраструктуре Meta и не являются нормой для PostgreSQL, Redis или другого парка. Полезен сам вывод из первичного источника — профиль доступа неоднороден, поэтому решение должно следовать за фактическим поведением нагрузки.

Linux DAMON представляет тот же класс задачи со стороны ОС: наблюдать за доступом с контролируемыми накладными расходами и использовать сведения для операций, учитывающих активность. Multi-Gen LRU оценивает рабочий набор по истории обращений. Это не внутренний алгоритм продукта, а подтверждение самостоятельной роли активности страниц.

Диагностика начинается с цены для сервиса

Количество занятых гигабайт нужно сопоставить с тем, что видит пользователь. Если p99 стабилен, SLO выполняется, а Linux PSI не показывает заметной потери полезного времени из-за памяти или ввода-вывода, высокая занятость ещё не требует срочной закупки. Она становится основанием изучить активность страниц на полном деловом цикле и оценить, насколько устойчив разрыв между резидентным и рабочим набором.

Если p99 растёт вместе с повторными возвратами недавно вытесненных страниц, граница быстрого уровня затрагивает критический путь. Одинаковое число page fault может иметь разную цену в зависимости от накопителя и поведения запроса, поэтому важен не счётчик сам по себе, а время, потерянное сервисом. PSI полезен именно как связь давления ресурсов с остановкой полезной работы.

Наблюдение включает обычный день, фоновые операции и известные пики. Среднее сглаживает критичный период, а максимальный RSS не сообщает, какие страницы создали пик. Нужна временная связь: фаза нагрузки, изменение активного набора, refault или ввод-вывод, затем p99 и доля запросов в SLO.

Decision tree переводит наблюдение в решение

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

  • Если RAM занята, а p99, PSI и SLO стабильны → наблюдать активность на полном деловом цикле → зафиксировать базовую границу резидентного и рабочего набора.
  • Если p99 и refault растут в одной повторяемой фазе → сопоставить момент возврата страниц с запросами и фоновыми операциями → защитить быстрый объём для этой фазы.
  • Если менее активный объём повторяется в разных циклах при устойчивом SLO → сравнить его со стоимостью DRAM и плотностью инстансов → рассматривать автоматическое физическое размещение.
  • Если пик создаёт совпадение пользовательской и фоновой работы → определить владельца окна и допустимую последовательность операций → включить совместный пик в резерв до изменения ёмкости.

Первая ветвь отделяет занятую память от проблемы, вторая — цену промаха от общего процента RAM. Третья формирует момент инвестиции: менее активные страницы устойчиво занимают DRAM, рост требует новых модулей или узлов, а сервис имеет понятную границу p99. Четвёртая выявляет совпадение тяжёлых фаз.

Владелец решения соединяет данные, платформу и деньги

DBA знает фазы запросов, обслуживание и изменение структуры данных. Платформенная команда наблюдает страницы, PSI, ввод-вывод и плотность размещения. Владелец сервиса задаёт SLO и критичные периоды, а финансы видят цену DRAM, узлов и простаивающей ёмкости. Решение о cold memory принадлежит этой группе, потому что ни один отдельный график не соединяет техническую активность со стоимостью полезной нагрузки.

Стоимость простаивающей DRAM проявляется в цене модулей, меньшем числе СУБД на узле и более ранней закупке сервера. Экономический эффект считают через плотность и стоимость обслуженной нагрузки при целевом SLO. Доля cold memory остаётся входным наблюдением, а не готовым процентом экономии.

Инвестировать в автоматизацию разумно, когда разрыв между резидентным и активным набором повторяется на нескольких деловых циклах, физическая DRAM ограничивает рост или плотность, а цена возвратов измерена через p99 и SLO. До этого момента наблюдение формирует доказательную базу. После него ручная поддержка правил по таблицам, ключам или временным окнам становится отдельной операционной работой, которая плохо следует за изменением нагрузки.

Предиктивное управление следует за активностью

gigaRAM работает ниже приложения и использует предиктивную математическую модель. По реальным обращениям она решает, что, куда и когда перемещать или возвращать между DRAM и NVMe, без ручного назначения hot/cold и без случайного swap. Модель не знает бизнес-смысл таблицы или ключа: её входом служит поведение страниц, а быстрый уровень сохраняется для ближайшей ожидаемой работы.

От статического деления такой подход отличается способностью пересматривать решение. Страница не получает пожизненный ярлык cold: при изменении фазы её ближайшая ценность меняется, и размещение может быть скорректировано. Связь наблюдения, результата и следующего решения подробно разобрана в статье про контур обратной связи памяти СУБД. Здесь важен момент до автоматизации — доказать, что холодный объём действительно существует во времени и имеет измеримую стоимость.

Для CTO итог выглядит конкретно. Команда перестаёт считать всю занятую RAM одинаково ценной, сохраняет SLO как границу решения и получает основание повышать плотность без линейного роста физической DRAM. gigaRAM становится архитектурным способом превратить наблюдаемую динамику страниц в управляемое размещение, а не обещанием универсального процента замещения.

Источники. Meta TMO использован как первичный отраслевой пример изменчивости cold memory и связи offloading с чувствительностью приложения; его результаты не перенесены на другие системы. Linux DAMON и Multi-Gen LRU подтверждают роль наблюдения за доступом и оценки рабочего набора как системного класса задач.

Документация Linux PSI использована для связи давления ресурсов с потерянным временем полезной работы. Документация PostgreSQL 17 — для shared_buffers, файлового кэша ОС и памяти операций запросов.

Описание технологии gigaRAM приведено только для механики предиктивного размещения страниц между DRAM и NVMe.