Файлы СУБД могут занимать несколько терабайт, но это не означает, что серверу нужен такой же объём RAM. В память одновременно попадает только часть данных, индексов и служебных структур, к которым обращается текущая нагрузка. При этом бюджет нельзя строить и по среднему потреблению: обслуживание, отчёты, восстановление, массовое обновление и сезонный трафик способны совпасть и сформировать другой пик.
Практический бюджет RAM начинается со страниц и структур, которые нужны сервису в рассматриваемой фазе. К рабочему набору добавляются совместный пик, память фоновых операций, потребности системы и резерв. Итог проверяется по p99 и доле запросов в пределах SLO, а не по проценту занятой RAM.
Размер базы и бюджет памяти измеряют разное
Размер базы отвечает на вопрос, сколько данных нужно хранить. В него входят исторические разделы, старые версии строк, редко читаемые индексы и архивные периоды, которые не участвуют в каждом запросе. RAM отвечает на другой вопрос: какой объём данных и служебных структур нужен с низкой задержкой в конкретный момент.
PostgreSQL использует собственный пул shared_buffers и одновременно опирается на файловый кэш операционной системы. Запросы получают память для сортировки и хеширования, причём несколько операций и сеансов способны работать одновременно. Размер файлов не описывает эту конкуренцию и повторное использование страниц.
У Redis память занимают представление объектов, служебные структуры, фрагментация распределителя и буферы. После удаления данных объём, видимый операционной системой, не всегда уменьшается сразу: живые и освобождённые объекты могут находиться на общих страницах. Снимок RSS поэтому не заменяет наблюдение во времени.
Рабочий набор виден только через фазы нагрузки
Рабочий набор — не постоянная доля базы. Утренний поток транзакций, дневные отчёты, ночное обслуживание и восстановление после сбоя обращаются к разным страницам. Новый релиз или изменение пользовательского поведения также способны быстро передвинуть границу активных данных. Бюджет, снятый в один спокойный час, фиксирует только одну фазу и создаёт ложную точность.
Наблюдение должно охватывать деловой цикл и критичные события. Важны повторные чтения страниц после вытеснения, давление памяти, ввод-вывод и изменение p99. Связь возвратов страниц с границей памяти разобрана в материале о рабочем наборе, refault и p99. Здесь эти сигналы определяют базовую часть бюджета RAM.
Linux PSI измеряет время, когда задачи не выполняют полезную работу из-за давления на процессор, память или ввод-вывод. Вместе с p99 и метриками СУБД он помогает увидеть, где граница рабочего набора становится значимой для SLO.
Пики нужно складывать по времени, а не по максимумам
После базового рабочего набора в расчёт входит добавочная память операций, которые действительно способны выполняться одновременно. Для PostgreSQL это могут быть параллельные сортировки, построение индекса, VACUUM, создание резервной копии и пользовательский трафик. Документация отдельно предупреждает, что work_mem задаётся на операцию, а не на весь сервер: несколько операций в одном запросе и несколько сеансов способны потреблять этот лимит одновременно.
Складывать максимумы всех процессов неверно, если они не совпадают по времени. Бюджет отражает подтверждённый совместный пик: например, транзакционный поток плюс разрешённое в том же окне обслуживание. Отдельный тяжёлый отчёт учитывается в своей фазе и сравнивается с её SLO.
Отдельно закладывается системный и операционный резерв для ядра, файлового кэша, буферов, агентов наблюдения, репликации и кратковременных отклонений. Его величина определяется архитектурой и историей пиков, а не универсальным процентом.
Условный расчёт показывает логику бюджета
Предположим, что наблюдения за полным деловым циклом показали активный набор 320 ГБ. В критичном окне вместе с ним работают запросы и фоновые процессы, добавляющие 96 ГБ. Операционной системе, файловому кэшу и инфраструктурным агентам выделено ещё 64 ГБ, а эксплуатационный резерв на кратковременное отклонение составляет 48 ГБ. Это условные числа для объяснения метода, а не рекомендация по конфигурации.
| Шаг расчёта | Условный объём | Накопленный бюджет | Что защищает |
|---|---|---|---|
| Активный рабочий набор | 320 ГБ | 320 ГБ | Обычную полезную нагрузку |
| Совместный пик запросов и фона | +96 ГБ | 416 ГБ | p99 в критичном окне |
| Система, файловый кэш и агенты | +64 ГБ | 480 ГБ | Работу платформы вокруг СУБД |
| Эксплуатационный резерв | +48 ГБ | 528 ГБ | Кратковременное отклонение от профиля |
Полученные 528 ГБ не становятся готовой спецификацией сервера. Архитектор сопоставляет бюджет с доступными конфигурациями, отказоустойчивостью и числом инстансов на узле. Для нескольких СУБД совместные пики анализируются так же, а не складываются по отдельным абсолютным максимумам.
Проверка проходит через результат сервиса. Если p99 остаётся в пределах SLO во всех заложенных фазах, бюджет защищает нужный объём работы. Если граница нарушается при возврате страниц или давлении памяти, пересматривается рабочий набор либо резерв.
Решение принадлежит не одной команде
DBA определяет фазы СУБД, фоновые операции и признаки изменения рабочего набора. Платформенная команда отвечает за память операционной системы, размещение инстансов и физические конфигурации. Владелец сервиса задаёт SLO и критичные периоды, а финансы связывают технический бюджет со стоимостью узлов и горизонтом роста. Без общего владельца среднее потребление легко превращается в закупочную норму, хотя оно не описывает ни пик, ни качество сервиса.
Момент инвестировать наступает, когда рабочий набор растёт повторяемо, а прежний резерв регулярно расходуется в одинаковых фазах. Дополнительный сигнал — рост p99 и PSI одновременно с refault или чтением страниц, которые снова нужны сервису. Тогда команда уже видит причинную связь между памятью и полезной нагрузкой и может сравнивать варианты: больше физической DRAM, изменение плотности узлов или управляемая многоуровневая ёмкость.
Экономическое сравнение начинается после формирования бюджета. В материале о стоимости полезной работы СУБД он становится входом для сравнения вариантов. Здесь важен предыдущий шаг: получить обоснованный объём RAM, не подменяя его размером базы или средним графиком.
Предиктивная ёмкость меняет форму бюджета
Когда значительная часть страниц меняет активность во времени, весь рассчитанный объём не обязательно должен постоянно находиться в физической DRAM. gigaRAM использует предиктивную математическую модель: по реальным обращениям она решает, что, куда и когда перемещать или возвращать между DRAM и NVMe, без ручного назначения hot/cold. Быстрый уровень обслуживает страницы с ближайшей ожидаемой ценностью, а управляемая ёмкость поддерживает меняющийся набор.
Для бюджетирования это означает разделение двух величин: сколько быстрой физической памяти необходимо для SLO и какой общий доступный объём нужен нагрузке во всех фазах. gigaRAM добавляет архитектурный вариант между линейной закупкой DRAM и уменьшением плотности СУБД. Его вклад оценивают теми же показателями — p99, числом запросов в пределах SLO, объёмом обслуженной нагрузки и полной стоимостью конфигурации.
Правильный бюджет поэтому остаётся живой моделью, а не числом, полученным один раз из размера файлов. Он обновляется, когда меняются рабочий набор, совместные пики, правила обслуживания или плотность размещения. Такой процесс даёт CTO понятную связь между данными, физической памятью, качеством сервиса и инвестициями, а инженерам — объяснимую границу, которую можно наблюдать в реальной нагрузке.
Источники. Документация PostgreSQL 17 по потреблению ресурсов использована для shared_buffers, файлового кэша ОС, work_mem и памяти фоновых операций. Документация Redis по оптимизации памяти — для различия логического набора данных, представления объектов и памяти, видимой ОС.
Документация Linux PSI подтверждает смысл показателей давления на процессор, память и ввод-вывод. Первичная работа TMO ASPLOS’22 используется как исследовательский контекст автоматического управления неоднородной памятью без переноса её результатов на другой продукт.
Описание технологии gigaRAM приведено только для механики предиктивного размещения страниц между DRAM и NVMe.