Виртуальный сервер с PostgreSQL видит обещанный объём RAM. Администратор базы настраивает внутренние буферы, операционная система использует остальную память под файловый кэш, отчёты и фоновые процессы рассчитывают на доступный запас. С точки зрения гостевой системы это настоящая рабочая ёмкость. На физическом хосте та же память может быть обещана и другим виртуальным машинам. Пока их потребности не совпадают, платформа работает экономно: установленная DRAM используется полнее, а не лежит резервом под каждый возможный максимум. Но при общем росте нагрузки гипервизор должен вернуть себе часть физической памяти, которую гости уже считают своей.

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

Одна обещанная память и одна физическая

Memory overcommit, или переподписка памяти, означает, что виртуальным машинам суммарно назначают больше RAM, чем физически установлено на хосте. Решение опирается на предположение: все гости не потребуют весь назначенный объём одновременно. Overcommit не создаёт новые микросхемы и не увеличивает физическую пропускную способность памяти. Гостевая память — объём, который видит операционная система внутри ВМ. Физическая память хоста — DRAM, из которой гипервизор действительно обслуживает работающие страницы всех гостей и собственные нужды. Между этими величинами нет обязательного равенства, пока фактически востребованная часть виртуальных машин помещается на сервере.

С СУБД это предположение требует осторожности. PostgreSQL использует shared_buffers для блоков таблиц и индексов, а Linux — свободную RAM для файлового кэша. Redis хранит рабочие данные в памяти и рассчитывает на предсказуемую скорость обращения. «Неиспользуемая» с позиции гипервизора ёмкость может быстро стать полезной для базы после смены запросов.

Как гипервизор возвращает память

Конкретные механизмы и их порядок зависят от гипервизора, версии и настроек. Общая задача одна: освободить физические страницы для более актуальной работы, не останавливая все ВМ. Для этого платформы могут просить гостя освободить память, сжимать её содержимое или переносить страницы на накопитель. Reclaim — общее название освобождения памяти под давлением. Ballooning, или «раздувание баллона», использует компонент внутри гостя: гипервизор просит его занять часть RAM, а операционная система выбирает страницы, от которых можно отказаться. Гость участвует в выборе, но знает тип и активность страниц, а не цену задержки SQL-запроса или Redis-операции.

Compression, или сжатие, пытается хранить часть страниц плотнее. Оно может отложить обращение к накопителю, но требует CPU и по-разному работает с разными данными. Host swap — подкачка на уровне хоста: гипервизор выносит страницу ВМ из DRAM на накопитель и возвращает при следующем обращении. Гостевая ОС может считать память доступной, хотя реальный доступ уже включает внешний путь. Эти реакции не бесплатны: освобождение кэша увеличивает повторное чтение, сжатие расходует CPU, подкачка добавляет I/O. Описание VMware или KVM объясняет класс механизма, а не обещает одинаковое поведение любого облака.

СУБД и гипервизор по-разному ценят страницу

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

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

Формальная ёмкость скрывает хвост задержки

Средняя задержка может оставаться спокойной, пока подкачка касается небольшой доли обращений. p99 — граница, в которую укладываются 99 процентов ответов, — показывает самые медленные операции, которые определяют тайм-ауты и очередь соединений. Страница, вынесенная хостом, возвращается ниже гостевой ОС. PostgreSQL видит долгое ожидание, но не обязательно ясный признак причины. Redis показывает паузу короткой операции, хотя внутри ВМ нет локального дефицита RAM.

Когда ожидание растёт, падает throughput — объём полезной работы за единицу времени. База дольше удерживает соединения и блокировки, а внешняя задержка превращается в очередь приложения. Формальная сумма гигабайт не меняется, но хост выполняет меньше транзакций и сильнее зависит от накопителя. Экономический результат считают по сохранённому качеству и завершённой работе, а не по обещанной памяти.

Гарантия, приоритет и потолок решают разные задачи

Виртуальная платформа обычно позволяет разделить три разных договора о памяти. Reservation, или резерв, заранее гарантирует ВМ некоторую физическую ёмкость. Shares, или доли приоритета, определяют относительное право гостей на ресурс при конкуренции. Limit, или лимит, задаёт верхний потолок потребления. Большой назначенный объём без резерва не равен гарантии, высокий приоритет не создаёт DRAM, а жёсткий лимит способен остановить рост.

Семантика зависит от платформы, но управленческое различие сохраняется. Критичной PostgreSQL может требоваться гарантированная часть быстрой памяти. Пакетной базе допустим больший риск. Redis с интерактивными операциями и Redis для восстанавливаемого кэша тоже могут заслуживать разных договоров. Гарантии имеют цену: зарезервированную ёмкость нельзя продать другому гостю. Отсутствие гарантий оплачивается непредсказуемым p99, восстановлением и общим I/O. Задача платформы — явно выбрать, где риск допустим.

Экономия заканчивается у физического ограничения

Overcommit выгоден, пока активные потребности гостей действительно различаются во времени, а реакции хоста не нарушают качество сервиса. Если PostgreSQL и Redis регулярно требуют обещанную память, платформа продаёт один физический ресурс нескольким владельцам в один момент. Дальше экономия превращается в ожидание. Прозрачный страничный уровень gigaRAM и memory overcommit решают разные задачи: первый может обслуживать подходящие менее активные страницы через NVMe, а второй распределяет ограниченную физическую RAM между гостями. Один механизм не заменяет контроль другого и не превращает одновременный горячий спрос в свободную память.

Для менее критичной нагрузки допустимо принять риск и использовать хост плотнее. Для базы, где задержка транзакции связана с деньгами или доступностью, разумнее гарантировать часть DRAM либо снизить переподписку. Выбор зависит от профиля работы и обязательств, а не от единого коэффициента для всей фермы. Главный вопрос звучит не «сколько виртуальной RAM удалось выдать», а «какую работу СУБД завершает при давлении хоста». Если p99, пропускная способность и восстановление остаются приемлемыми, переподписка приносит пользу. Если гипервизор регулярно отбирает полезные страницы, инфраструктура экономит гигабайты ценой сервиса.

Источники. VMware — Understanding Memory Resource Management описывает overcommit, ballooning, сжатие, host swap, резервы, приоритеты и лимиты.

Red Hat — Overcommitting memory with KVM подтверждает общую модель переподписки и роль подкачки в KVM.

Microsoft Research — Resource Central используется для тезиса о прогнозировании потребления ВМ без физического исчерпания.

Google Research — Borg описывает упаковку задач, переподписку и изоляцию.

Google SRE — Monitoring Distributed Systems подтверждает значение хвоста задержки и насыщения.

Redis Latency связывает окружение и подкачку с задержкой Redis.

PostgreSQL 17 — Resource Consumption объясняет shared_buffers и файловый кэш ОС.

Meta Engineering — TMO показывает прозрачный перенос страниц и разную чувствительность нагрузок.

Страница продукта используется только для описания механики и позиционирования решения.