Память «на всякий случай»: цена перестраховки за год

MAATRIX

При заказе сервера почти все интуитивно берут RAM с запасом — «а вдруг не хватит». Логика понятная: апгрейд тарифа занимает минуты, а падение процесса из-за нехватки памяти — это инцидент, разбор которого займёт вечер и нервы. Проблема в том, что этот запас редко считают — его просто берут «с потолка», удваивая или утраивая расчётную потребность, и потом год за годом платят за память, которая простаивает. Разберём, как оценить реальное потребление RAM (не только среднее, но и пиковое — это принципиально другая метрика для памяти, чем для CPU), сколько стоит перестраховка за год и где проходит разумная граница между экономией и риском OOM killer.

Почему память нельзя мерить теми же мерками, что и CPU

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

С памятью всё жёстче, потому что RAM — это не делимый по времени ресурс, а конечный объём. Когда процессу не хватает памяти прямо сейчас, ядро не может «выдать её попозже» — оно либо находит свободные страницы, либо начинает выгружать данные в swap (если он есть и не исчерпан), либо, когда деваться уже некуда, включается OOM killer и просто убивает один из процессов, чтобы освободить память для остальных. Разница принципиальная: недостаток CPU — это медленнее, недостаток RAM в пике — это упавший процесс, оборванные соединения, а иногда и повреждённые данные, если процесс убили посреди записи.

Отсюда и разная цена ошибки при выборе тарифа. Занизили запас CPU — пользователи подождут лишнюю секунду. Занизили запас RAM — в худшем случае ляжет база данных в момент пиковой нагрузки, то есть именно тогда, когда сервис нужен больше всего. Именно эта асимметрия и толкает к перестраховке: страх перед OOM killer стоит дороже, чем страх перед троттлингом CPU, поэтому память переплачивают охотнее и меньше об этом задумываются.

Среднее потребление RAM почти ничего не говорит о риске

Главная методическая ошибка при оценке «сколько памяти нам реально нужно» — смотреть на средний расход за неделю или месяц. Средний показатель сглаживает именно то, что должно вас интересовать: кратковременные всплески. Сервис может держать среднюю загрузку памяти в 30-40% и при этом раз в сутки, в момент бэкапа или batch-обработки, упираться в 95% с последующим OOM kill — а в усреднённом графике за месяц этот всплеск почти не будет заметен, просядет в общем шуме.

Поэтому корректная методика — смотреть не на одну цифру, а на распределение минимум по трём срезам:

• Baseline — сколько памяти сервисы держат в состоянии покоя, без нагрузки. Это тот минимум, ниже которого RAM физически не может опуститься.
• Типичный рабочий диапазон — median и, отдельно, 95-й перцентиль потребления в обычные рабочие часы. Перцентиль важнее среднего: он показывает, сколько памяти реально требуется в 95% времени, а не «в среднем».
• Максимум за наблюдаемый период — абсолютный пик, который зафиксировали графики. Именно эта цифра, а не средняя, определяет, хватит ли вам памяти в самый неудачный момент.

Смотреть стоит не на голый free, а на реальное потребление приложений (RSS процессов, used без учёта page cache, который ядро вытеснит само при нехватке места) и на давление на память отдельно — в Linux это метрики PSI (/proc/pressure/memory), которые прямо показывают, сколько времени процессы простаивают из-за нехватки памяти, ещё до того, как дело дойдёт до OOM killer. Разворачивать самописные скрипты для этого не обязательно — граф с history и алертами по перцентилям проще получить готовым инструментом, например через установку Netdata на VPS: он из коробки хранит историю по памяти, своп и page cache раздельно, и по нему видно пиковые всплески, которые в еженедельном отчёте усреднённой сводки просто теряются.

Минимальный срок наблюдения перед тем, как делать выводы о нужном объёме RAM, — две-четыре недели с захватом хотя бы одного полного цикла нагрузки: рабочих дней, выходных, регламентных задач (бэкапы, ротация логов, batch-джобы), и по возможности одного пикового события (распродажа, релиз, всплеск трафика). Оценка по трём дням «типичной» нагрузки систематически занижает реальный пик, потому что редкие события просто не успевают попасть в выборку.

Куда прячется переплата за память «на всякий случай»

Перестраховка по памяти обычно проявляется не в одном решении, а накапливается из нескольких привычек:

• Запас берут не от пика, а от интуиции. Вместо расчёта «пиковое потребление плюс 30-40%» берут просто следующий по каталогу тариф, который может быть кратно больше факта.
• Запас закладывают на каждом уровне отдельно. Разработчик закладывает запас в лимит контейнера, DevOps — ещё запас в размер виртуалки поверх суммы контейнерных лимитов, и в итоге накапливается двойная, а то и тройная перестраховка, потому что никто не видит картину целиком.
• Тариф не пересматривают после снижения нагрузки. Сервис оптимизировали, ушли от одного тяжёлого процесса, перевели кэш на отдельный инстанс — а тариф остался прежним «на всякий случай», хотя реальная потребность в памяти давно снизилась.
• Боятся даунгрейда сильнее, чем стоит. Смена тарифа на VPS с меньшим объёмом RAM у большинства провайдеров не требует переустановки системы и занимает считаные минуты — но воспринимается как рискованная операция, поэтому её просто откладывают на неопределённый срок.

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

Как посчитать цену перестраховки за год

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

1. Возьмите пиковое потребление RAM за 2-4 недели наблюдения (не среднее!)
2. Добавьте разумный запас на рост и непредвиденные всплески: 30-50%
3. Округлите вверх до ближайшего доступного объёма тарифа
4. Сравните получившийся объём с тем, что оплачивается сейчас
5. Разница в стоимости между текущим и расчётным тарифом × 12 месяцев
   = цена перестраховки за год

Если пиковое потребление за месяц наблюдения — условно 60% от объёма текущего тарифа, а не 95%+, у вас, вероятно, есть пространство для оптимизации: разница между текущим тарифом и «пик + 30-40% запаса» и есть переплата. Если же пик регулярно подбирается к 85-90% от объёма тарифа — это, наоборот, сигнал, что текущего запаса едва хватает, и экономить тут не стоит.

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

Важная оговорка: у разных провайдеров и разных линеек тарифов шаг между объёмами RAM разный (где-то 1 ГБ, где-то 2-4 ГБ), поэтому расчётный объём не всегда попадает точно в границу тарифа — иногда выгоднее взять тариф с небольшим избытком, чем гнаться за точным попаданием — разрыв между соседними планами и так вынуждает переплачивать за целую ступень. Это нормально и не противоречит идее избавления от перестраховки: речь не о том, чтобы упереться в 100% использования, а о том, чтобы запас был осознанным, а не случайным.

Цена недооценки: почему для RAM это больнее, чем для CPU

Честная картина требует взвесить не только цену переплаты, но и цену ошибки в другую сторону — если памяти вдруг не хватит в пике. Здесь сценарии развиваются по нарастающей.

Первый уровень — swap, если он настроен. Ядро выгружает на диск страницы памяти, к которым давно не обращались, освобождая место для активных процессов. Формально сервис продолжает работать, но операции с выгруженными страницами резко замедляются — на порядок и больше по сравнению с обращением к RAM, особенно если диск не NVMe. Для стабильного сервиса под нагрузкой это ощущается как внезапное зависание на секунды при, казалось бы, обычных операциях.

Второй уровень — OOM killer, если swap отключён или тоже исчерпан. Ядро принудительно выбирает и завершает процесс, который потребляет больше всего памяти, чтобы не допустить полного краха системы. Проблема в том, что OOM killer выбирает жертву по своей эвристике (oom_score), а не по важности процесса для бизнеса — под удар может попасть основной сервис или база данных, а не второстепенный вспомогательный скрипт. Логика выбора и способы на неё повлиять разобраны в статье про то, как ядро выбирает жертву для OOM killer — если процесс критичен, его oom_score_adj стоит понижать заранее, а не разбираться постфактум, почему упал именно он.

Третий уровень — каскадный эффект. Если убитый процесс держал открытые соединения (например, пул подключений к базе), их резкое обрывание может спровоцировать волну переподключений от клиентов, что создаёт дополнительный всплеск нагрузки уже на восстанавливающийся сервис — и в неудачном случае система входит в цикл повторных падений. Именно поэтому восстановление после OOM kill стоит планировать заранее, а не разбираться с ним впервые уже во время инцидента.

Асимметрия последствий и есть главный аргумент за то, что для памяти запас должен быть больше, чем для CPU: троттлинг CPU в пике почти всегда обратим и сам себя нормализует, а нехватка RAM в пике может привести к полноценному инциденту с восстановлением, а не просто к временному замедлению. Именно поэтому «убрать перестраховку» для RAM не означает «убрать запас вообще» — это про замену интуитивного тройного запаса на измеренный и обоснованный.

Как найти баланс между переплатой и риском

Практическая рекомендация складывается из нескольких шагов, и без замера первого шага все остальные бессмысленны:

1. Соберите данные за 2-4 недели по пиковому, а не среднему потреблению RAM — через мониторинг, а не разовые проверки free -h вручную.
2. Разделите память по назначению. Отдельно посчитайте базовое потребление ОС и системных служб, отдельно — приложений, отдельно — буферов СУБД, если она на этом же сервере. Суммарный запас закладывайте один раз на сумму, а не на каждый компонент по отдельности.
3. Заложите запас от пика, а не от среднего: пиковое потребление плюс 30-50% в зависимости от того, насколько предсказуема ваша нагрузка. Для сервисов с сильной сезонностью (распродажи, всплески трафика по расписанию) запас нужен больше, для стабильной равномерной нагрузки — меньше.
4. Настройте алерты на приближение к порогу, а не только на факт нехватки. Оповещение при устойчивом использовании выше 75-80% даёт время на плановый апгрейд тарифа — вместо аварийного апгрейда посреди инцидента.
5. Пересматривайте тариф раз в квартал или после значимых изменений в коде и трафике, а не откладывайте до следующего инцидента. Даунгрейд тарифа для VPS обычно занимает минуты и не требует переустановки — бояться его больше, чем самой переплаты, не стоит.
6. Держите отдельный, осознанный запас под нерегулярные события — бэкапы, миграции, batch-обработку — если они выполняются на том же сервере и в моменте поднимают потребление памяти сверх обычного пика.

Отдельно стоит развести уровни, на которых закладывается запас, чтобы не платить за него дважды: если у вас лимиты памяти выставлены на уровне контейнеров (mem_limit, --memory), запас на уровне виртуальной машины должен считаться от суммы контейнерных лимитов, а не добавляться поверх неё ещё раз «для надёжности». Смежная тема — распределение процессорного времени между теми же контейнерами и виртуалками, где работает похожая логика запаса и переплаты; она разобрана в статье про потолок оверкоммита CPU и памяти.

Частые вопросы