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

Средняя загрузка всё ещё может выглядеть приемлемой. Но p99 — граница, в которую укладываются 99 процентов ответов, — уже ухудшается: небольшая доля самых медленных операций перестаёт соответствовать ожиданиям бизнеса. Плотность виртуальных серверов — это количество изолированных программных серверов, которое инфраструктура размещает на одном физическом хосте. Чем выше плотность, тем меньше оборудования приходится на одну ВМ. Экономия реальна только пока общий хост выдерживает не среднюю, а нужную работу в совпадающих критичных фазах.

Среднее создаёт ложное свободное место

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

У пиков СУБД есть причины и расписание

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

Особенно опасен общий перезапуск после обновления. ВМ возвращаются к работе почти одновременно, базы заново читают данные, реплики догоняют изменения, а приложения восстанавливают соединения. Ранее независимая нагрузка получает одну причину и момент старта. Такой совместный всплеск называют коррелированным пиком: потребности растут вместе из-за общего события. Им может быть релиз, отказ узла, переключение реплик, утренний трафик или корпоративный календарь.

Независимые ВМ становятся соседями

Граница виртуальной машины отделяет процессы и настройки, но не создаёт отдельный физический сервер. Все ВМ хоста используют общие DRAM, процессорные ядра, пропускную способность памяти и путь к накопителям. Изоляция распределяет ресурсы, однако не отменяет их конечность. Когда базы одновременно увеличивают активный набор, они претендуют на одну быструю память. Возврат вытесненных страниц добавляет чтение, а контрольная точка PostgreSQL и сохранение Redis делают общий I/O ещё одним ограничением.

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

Отказ проверяет запас лучше обычного дня

Нормальный режим — не единственное состояние кластера. Если один физический сервер потерян или выведен на обслуживание, его виртуальные машины должны запуститься на оставшихся. Вместе с ними переезжают пользовательские запросы, фоновые процессы и необходимость заново прогреть данные. Резерв N+1 означает, что площадка продолжает выполнять требуемую работу после потери одного элемента — например, хоста. Для этого оставшейся части кластера нужны реальная ёмкость и производительность, способные принять его нагрузку.

Плотность обычного дня поэтому не равна допустимой плотности после отказа. На выжившем хосте может одновременно появиться новая ВМ, вырасти рабочий набор уже работающих баз и усилиться I/O из-за восстановления. Запас, который до аварии выглядел неиспользуемым, оказывается частью услуги. Запустить гостевую систему недостаточно. PostgreSQL должна обслуживать транзакции во время восстановления, а Redis — вернуть требуемую задержку после прогрева и синхронизации. Иначе формальная отказоустойчивость становится затянувшейся деградацией. Критичные базы можно отделить от широких сканирований, а обслуживание и копирование — развести во времени. Иногда высокая плотность несовместима с N+1, и аварийный запас нельзя продавать второй раз.

История помогает, но не обещает будущий максимум

Исследование Microsoft Resource Central показывает подход, при котором планировщик использует историю ВМ и прогноз верхней области потребления, чтобы эффективнее размещать нагрузку без физического исчерпания ресурсов. Важен принцип, а не перенос результатов чужого облака на свою ферму. Прогноз ограничен прошлым. В истории может не быть одновременного закрытия месяца и восстановления после аварии, нового релиза или резкого роста клиентов.

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

Экономия начинается с предсказуемой плотности

Хорошая плотность — не максимум запущенных ВМ, а число баз, которое инфраструктура обслуживает с требуемой задержкой, пропускной способностью и резервом. Разнести связанные задания, изменить расписание или выделить критичную СУБД бывает выгоднее, чем лечить общий пик. Прозрачный страничный уровень gigaRAM может обслуживать через NVMe подходящую менее активную часть памяти, оставляя более активные страницы в DRAM. Такой подход способен помочь отдельной базе с устойчивым менее активным объёмом, но не создаёт резерв для одновременного горячего пика и не отменяет планирование мощности после отказа.

Если базы в критической фазе требуют данные одновременно, более медленный уровень получает общий поток возвратов. При узком месте в CPU или I/O добавленная ёмкость не превращается в работу; честным выводом может быть меньшая плотность и больший запас DRAM. Решение о консолидации принимают по стоимости выполненной работы при прежнем качестве, а не по красоте среднего процента. Нужно знать, какие события связывают ВМ, что происходит после потери хоста и сохраняется ли p99 у приложений. Тогда запас перестаёт выглядеть пустующей памятью: это оплаченная способность пережить общий пик.

Источники. Google Research — Large-scale cluster management at Google with Borg описывает размещение, управление ресурсами, изоляцию и устойчивость крупного кластера.

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

VMware — Understanding Memory Resource Management объясняет консолидацию, активную память и управление памятью хоста.

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

Redis Administration описывает запас памяти при фоновых операциях и репликации.

PostgreSQL 17 — Resource Consumption и WAL Configuration подтверждают роль памяти, кэша ОС и контрольных точек.

Meta Engineering — TMO показывает различия профилей нагрузки и менее активной памяти.

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