Как выбрать сервер: сколько ядер и памяти нужно проекту

Сервер с 8 vCPU и 32 ГБ RAM может работать медленнее машины с четырьмя физическими ядрами и быстрым NVMe-диском, если проект упирается в базу данных или память. Поэтому выбирать конфигурацию только по числу ядер опасно: сначала нужно понять профиль нагрузки, затем заложить запас и проверить его реальными метриками. Ниже — практическая схема для Linux-серверов с веб-приложением, базой данных и фоновой обработкой; примеры ориентированы на актуальные ветки PostgreSQL 16–17 и Docker Engine 26+, но конкретные требования зависят от стека.

Сначала опишите нагрузку, а не сервер

Для расчёта нужны не абстрактные «посетители в месяц», а пиковые события. Десять тысяч просмотров за сутки и тысяча запросов за минуту — совершенно разные задачи. В первом случае сервер большую часть времени простаивает, во втором ему нужен запас для короткого пика.

• Пиковое число запросов в секунду к приложению и к базе данных.
• Количество одновременно работающих пользователей, загрузок и фоновых задач.
• Размер базы данных, индексов, файлов пользователей и резервных копий.
• Доля операций: чтение, запись, поиск, генерация отчётов, обработка изображений или видео.
• Требуемое время ответа: 200 мс для API и 2 секунды для отчёта — разные ограничения.

Если проект уже работает, снимите данные хотя бы за период с обычным днём и пиком. Смотрите загрузку CPU, объём доступной памяти, swap, задержку диска, количество соединений к базе и p95 времени ответа. Если проекта ещё нет, используйте стартовую конфигурацию из таблицы ниже как гипотезу, а не как гарантию.

Правильный сервер — не самый мощный. Это конфигурация, в которой известны главный ограничитель и цена следующего шага.

Как распределять CPU и RAM

Процессор: важны не только ядра

CPU нужен приложению для выполнения кода, базе — для запросов и сортировок, а системе — для TLS, сжатия, логирования и фоновых процессов. Четыре быстрых ядра часто лучше восьми медленных vCPU, если запросы выполняются последовательно. При параллельной обработке изображений, сборке, очередях задач и аналитике дополнительные ядра дают больший эффект.

У виртуального сервера vCPU не всегда равен отдельному физическому ядру. Провайдер может делить процессор между арендаторами, поэтому две машины с одинаковым числом vCPU покажут разное время ответа. Сравнивайте не только тарифы, но и тип CPU, гарантии ресурсов, результаты собственного теста и поведение под соседней нагрузкой.

Память: дефицит дороже избытка

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

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

Swap — дисковое пространство, которое ядро Linux использует как медленное расширение оперативной памяти. Его наличие не означает, что серверу хватает RAM: важно, насколько часто система обращается к swap.

Стартовые конфигурации для разных задач

Ниже приведены безопасные отправные точки для одного сервера. Это не нормативы и не обещание производительности. На итог влияют код, запросы, тип диска, кеширование и ограничения провайдера.

Если веб-приложение и база живут на одной машине, оставляйте резерв минимум под систему, мониторинг и кратковременный пик. Не отдавайте базе и контейнерам всю RAM: при нулевом запасе даже обычный деплой может закончиться нехваткой памяти.

Выберите архитектуру, а не только тариф

Один сервер

Один экземпляр с приложением, базой и воркерами дешевле и проще в эксплуатации. Он подходит для старта, внутреннего сервиса и проекта, для которого допустим простой во время обновления. Цена — общая точка отказа: проблема с диском, ядром или обновлением останавливает всё сразу.

Приложение отдельно, база отдельно

Так проще независимо увеличивать CPU приложения и RAM базы, а отказ одного слоя не обязательно выключает другой. Но появляются сетевые задержки, отдельные резервные копии, настройка доступа и два сервера вместо одного. Для базы важна не только пропускная способность канала, но и стабильная задержка.

Горизонтальное масштабирование

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

Как проверить, что конфигурация подходит

Проверяйте не среднее значение, а пик и хвост распределения. Средний ответ 100 мс может соседствовать с p99 в 5 секунд: именно его увидит часть пользователей во время нагрузки.

1. Зафиксируйте сценарии. Опишите типовые запросы, логин, поиск, оформление заказа, загрузку файла и фоновые задачи. Для каждого задайте объём и допустимое время ответа.
2. Запустите нагрузочный тест на копии. Используйте обезличенные данные и не направляйте тест на рабочую базу без согласования. Увеличивайте параллельность ступенями, чтобы увидеть момент деградации.
3. Снимите ресурсы по слоям. Отдельно смотрите приложение, веб-сервер, базу, очередь и диск. Общие 70% CPU ничего не объясняют, если один процесс уже упирается в одно ядро.
4. Проверьте отказ. Убедитесь, что восстановление резервной копии действительно работает, а заполнение диска, остановка базы и перезапуск контейнера дают ожидаемый результат.
5. Оставьте план увеличения. Запишите, что вы будете добавлять первым: RAM, CPU, IOPS, отдельный сервер базы или несколько экземпляров приложения. Критерий должен быть измеримым.

Что ломается первым

• Память. Контейнеры и база начинают конкурировать с кешем, появляется swap, растут задержки и срабатывает OOM Killer. Проверьте лимиты контейнеров и реальные пики потребления.
• Диск. Быстрый CPU не компенсирует медленные случайные операции. Частые признаки — высокий iowait, растущая очередь диска и медленные запросы при невысокой загрузке CPU.
• Соединения. Приложение может создать больше подключений к базе, чем она способна обслужить. Увеличение числа воркеров без расчёта пула соединений усугубит проблему.
• Один поток. Если критичный участок работает последовательно, добавление vCPU почти не поможет. Ищите блокировку, медленный запрос, синхронный вызов или ограничение конкретного процесса.
• Диск и резервные копии. Логи, загрузки и бэкапы способны заполнить раздел быстрее, чем ожидает команда. Отдельно задайте политику хранения и оповещение о свободном месте.

Где расчёт перестаёт работать

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

Не смешивайте вертикальное и горизонтальное масштабирование без плана. Увеличение RAM часто быстро устраняет нехватку кеша, но не исправит плохой SQL-запрос. Добавление экземпляров приложения поможет при независимых запросах, но не спасёт единственную перегруженную базу.

Что делать дальше

Выберите минимальную конфигурацию из таблицы, зафиксируйте четыре сценария нагрузки и настройте сбор CPU, RAM, swap, iowait, дискового пространства, числа соединений и p95/p99 ответа. Через неделю реальной эксплуатации сравните пики с заложенным запасом. Первым увеличивайте тот ресурс, который регулярно достигает лимита и подтверждается задержками, а не тот, который проще добавить в панели провайдера.