Сколько ОЗУ и ядер заложить на сервер, чтобы проект не упал после запуска

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

Ошибиться можно в обе стороны

Сервер подводит не только падением. Переплата встречается ничуть не реже, только остаётся незаметной, потому что деньги уходят на мощность, которая так и не пригодилась. Опрос IT-руководителей от VMware показал, что почти половина считает, что свыше 25% облачных расходов уходит впустую, а 31% говорят о потерях больше половины бюджета. Цифры собраны по корпоративным облакам, но логика применима и к обычному VPS, потому что тариф «с запасом на всякий случай» означает ежемесячный платёж за железо, которое просто простаивает, если наплыва так и не случилось.

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

Отправная точка: грубые ориентиры по типу проекта

Точных универсальных цифр «на N пользователей нужно X гигабайт» не существует, потому что слишком много зависит от конкретного кода. Для старта такие ориентиры всё равно точнее, чем гадание.

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

Почему советы хостеров расходятся

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

Есть и другая ловушка, и она в том, что легко спутать типы нагрузки. Ориентиры вроде «пол-гигабайта на одного пользователя» родом из терминальных серверов и 1С, где у каждого человека держится своя полноценная сессия с интерфейсом. Обычное веб-приложение или бот устроены иначе, ведь запрос пришёл, обработался, соединение закрылось, и ресурсы освободились. Поэтому легко перенести формулу из одного мира в другой, если раньше не сталкивался с этой разницей и читал только общие статьи хостеров.

Что реально ест ресурсы

Ядро Linux устроено жёстко. Когда память заканчивается, срабатывает механизм OOM Killer и обрывает процесс, выбранный по внутренней эвристике, без возможности корректно завершиться. По оценке администраторов, именно нехватка оперативной памяти стоит за 80-90% случаев, когда сервер регулярно виснет каждые 2-8 часов. Проверить это на своём сервере просто, потому что команда dmesg | grep -i oom показывает записи вида «Killed process» с именем убитого процесса, если OOM Killer действительно срабатывал.

У нехватки ресурсов есть и зеркальная проблема, с противоположным знаком. Мессенджер на 78 000 активных пользователей в месяц получил счёт за облачную инфраструктуру больше 100 000 долларов из-за бага в коде. Обновление списка чатов отправляло 50 000 лишних запросов разом, а сервис работал на автомасштабируемой платформе и вообще не падал. Вместо этого он молча сжигал бюджет, пока кто-то не заметил счёт. Перенос на обычный VPS с 8 ядрами и 16 гигабайтами (около 50 долларов в месяц) снизил расходы больше чем в 2000 раз. Автомасштабирование в этой истории просто прятало неэффективный код, вместо того чтобы заставить его починить, а размер сервера был почти ни при чём.

Как проверить перед запуском

Прогнать нагрузочный тест – не значит писать код, поэтому разработчик в штате для этого не нужен. Loader.io бесплатно эмулирует до 10 000 обращений через веб-интерфейс без единой строчки кода. k6 умеет записывать реальный трафик прямо из браузера и сам собирает по нему тестовый сценарий. Есть и российский вариант, Яндекс.Танк, тоже бесплатный и с визуализацией результатов.

Один реальный лог такого теста показывает, зачем это вообще нужно. Первый прогон одного проекта споткнулся о race condition в общем кэше (это ситуация, когда два параллельных запроса одновременно пытаются обновить один и тот же участок памяти и портят друг другу результат) и выдал 46% ошибок. На тихом ручном тестировании такой баг почти невозможно заметить, потому что для него нужны именно одновременные запросы, а последовательные клики одного тестировщика его не провоцируют. После исправления тот же тест показал 226 запросов в секунду в среднем и 100% успешных ответов. Без нагрузочного теста этот баг ждал бы своего часа ровно до первого реального всплеска посетителей.

Диагностика уже работающего сервера тоже не требует специальных программ. free -h показывает, сколько памяти реально свободно, а top – какой процесс её ест прямо сейчас. Если vmstat 1 10 держит в колонках si/so не пустые значения, система уже ушла в своп и задыхается. А узнать, срабатывал ли OOM Killer раньше, помогает команда dmesg | grep -i oom.

FAQ

Сколько RAM реально нужно небольшому приложению на старте?

Простому боту на Python или Node.js без базы данных обычно хватает 512 мегабайт – 1 гигабайта. Как только подключается база, реалистичнее закладывать 2-4 гигабайта и несколько ядер. Полная таблица по типам проектов приведена выше.

Как понять, что сервера не хватит, до того как сайт упадёт?

Нагрузочный тест перед запуском (Loader.io, k6 или Яндекс.Танк) покажет узкие места ещё на тестовом трафике. Отдельно стоит проверить, не взята ли формула расчёта из чужого контекста, потому что нагрузка терминальных сессий и 1С в разы выше, чем нужно обычному веб-приложению.

Можно ли сначала взять минимальный тариф, а потом расширить?

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

Заключение

И завышенный тариф, и нехватка ресурсов – реальные риски при выборе конфигурации, просто в противоположных направлениях. Таблица ориентиров по типу проекта помогает только на старте. Окончательный ответ даёт нагрузочный тест на собственном коде, проведённый до того, как на сервер придут реальные пользователи.