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

Для CTO практический вопрос звучит не как «сколько ватт потребляет гигабайт». Важно, сколько полезной нагрузки помещается в энергетический контур и сохраняет ли сервис целевые SLO и p99 при совместных пиках.

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

Мощность стойки становится пределом раньше площади

IEA сообщила, что потребление электроэнергии центрами обработки данных выросло на 17% в 2025 году. Агентство связывает дальнейший рост со спросом на вычисления, ограничениями энергоснабжения и сроками подключения. Эти глобальные данные не заменяют замер конкретного ЦОД, но показывают: мощность стала производственным ресурсом.

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

Память участвует в ограничении двумя путями. Модули входят в потребление узла, а недостаточная ёмкость заставляет добавлять целый сервер с процессорами, сетью, вентиляторами и блоками питания. Часто главный резерв находится не в отдельном DIMM, а в том, чтобы обслужить тот же объём данных меньшим числом машин.

Плотность СУБД определяется не средним, а совместным пиком

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

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

Архитектору нужны два подтверждения: обслуженная нагрузка остаётся в пределах SLO, а измеренное потребление стойки на единицу этой нагрузки улучшается. Иначе высокая плотность не высвобождает энергетический резерв.

Управляемая память меняет физическую конфигурацию

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

Для энергетической задачи важно не само число перемещений и не объём адресуемого NVMe. Ценность появляется, когда управляемый уровень позволяет держать в физической DRAM тот объём, который нужен активной работе и согласованному запасу, а общую ёмкость расширять без пропорционального добавления модулей. Тогда меняется либо состав нового узла, либо число инстансов на существующем сервере, либо срок появления следующей машины.

NVMe также требует энергии, а перенос страниц создаёт ввод-вывод. Поэтому эффект оценивают на целой конфигурации: сервере под реальной нагрузкой, накопителе, охлаждении и числе операций в пределах SLO.

Исследование Meta TMO подтверждает общий класс автоматического управления неоднородной памятью и связь с мощностью инфраструктуры. Его реализация и результаты относятся только к парку Meta; здесь это независимый пример направления.

Условный расчёт показывает роль плотности

Рассмотрим учебный пример без рыночных цен. В стойке работают восемь одинаковых узлов, каждый обслуживает четыре инстанса СУБД при целевом p99. Стойка выполняет полезную работу 32 инстансов. Полное энергопотребление одного узла под этой нагрузкой примем за одну условную единицу, поэтому на один обслуживаемый инстанс приходится 8 / 32 = 0,25 условной энергетической единицы.

Теперь предположим, что после изменения архитектуры памяти измерения подтверждают пять инстансов на узел при том же профиле запросов, запасе на совместный пик и целевом p99. Те же восемь узлов обслуживают уже 40 инстансов, а показатель становится 8 / 40 = 0,20 единицы на инстанс. В рамках принятых условий стоимость энергетического ресурса на обслуженную нагрузку снизилась на 20%, хотя общая мощность стойки не изменилась.

Есть и другой способ использовать результат. Для прежних 32 инстансов достаточно семи узлов с запасом до 35, поэтому условное потребление парка уменьшается с восьми до семи единиц. Это сокращение на 12,5% в учебной модели, а не прогноз для реальной площадки. На практике вместо единиц подставляют измеренные киловатт-часы, учитывают изменившееся потребление памяти и NVMe, охлаждение, резервирование и стоимость программного слоя.

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

SLO связывает инженера, владельца сервиса и энергетику

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

Совместное владение защищает от односторонних решений. Уплотнение не считается успешным при нарушении SLO, а сокращение узлов — пока оставшийся парк не подтвердил ту же нагрузку и совместные пики.

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

p99 нужен потому, что средняя задержка скрывает редкие медленные ответы. При высокой плотности хвост распределения раньше среднего показывает конкуренцию за память, процессор или ввод-вывод. Решение опирается на критичный период, а не на спокойный среднесуточный график.

Инвестиция оправдана, когда рост упирается в физический контур

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

Решение принимает не один администратор. Платформенная команда вместе с владельцем сервиса определяет допустимую плотность и SLO, эксплуатация ЦОД подтверждает энергетическую границу, а финансовая сторона сравнивает стоимость одинаковой обслуженной нагрузки. Такой порядок переводит разговор из «сколько RAM можно убрать» в «сколько роста помещается в доступные киловатты».

Применение gigaRAM в этой модели означает инфраструктурный способ разорвать линейную связь между ростом адресуемых данных и закупкой физической DRAM. Универсальный процент плотности из этого не следует: итог зависит от поведения страниц, профиля запросов, конфигурации NVMe и требования к задержке. Но критерий решения остаётся однозначным — больше полезной нагрузки в том же энергетическом контуре при сохранённом SLO.

Источники. IEA, 16 апреля 2026 года подтверждает рост электропотребления ЦОД в 2025 году и ограничения энергоснабжения. IEA — Energy and AI даёт системный контекст нагрузки ЦОД.

Microsoft Research — Flikker служит первичным источником о роли обновления данных DRAM в энергопотреблении памяти; его метод и показатели не переносятся на современные конфигурации. Meta TMO подтверждает отраслевой класс автоматического управления неоднородной памятью ради стоимости и мощности, но описывает только инфраструктуру Meta.

Технология gigaRAM — единственная коммерческая ссылка и источник описания предиктивного размещения между DRAM и NVMe. Ни один из источников не задаёт универсальный процент экономии энергии или плотности СУБД.