Как рассчитать необходимые ресурсы VPS: CPU, RAM и диск

Выбор VPS начинается не с того, чтобы заказать тариф с запасом «на всякий случай», а с честной оценки трёх ресурсов: процессора, оперативной памяти и диска. Если хотя бы один из них окажется в дефиците, сервер начнёт тормозить — даже если по остальным параметрам всё выглядит прилично. Это как в ЦОДе: все стойки запитаны, но если на одной линии перегруз по току, она выбьет весь ряд.

С чего начать расчет VPS

Прежде чем смотреть тарифы, стоит разобраться не с абстрактным «проектом», а с конкретным профилем нагрузки. Один и тот же сайт на разных движках, с разной базой, схемой кеширования, числом фоновых задач и объёмом файлов будет потреблять совершенно по-разному. Например, WordPress с десятью плагинами и магазин на чистом PHP — это две разные планеты по требованиям.

Что нужно выяснить заранее

• Что конкретно будет крутиться на сервере: сайт, API, база, VPN, панель управления, почтовый сервер или сразу несколько контейнеров. Чем больше ролей одновременно, тем выше требования к CPU и RAM, потому что процессы конкурируют за ресурсы.
• Есть ли пиковые нагрузки: распродажи, рассылки, ночные задачи, импорт данных. Именно они чаще всего валят сервер, который в обычное время работает стабильно.
• Используется ли база данных локально или она вынесена на отдельный сервер. Локальная БД делит с приложением и процессор, и память, и дисковый I/O.
• Есть ли тяжёлые операции: генерация отчётов, обработка изображений, архивирование, бэкапы. Всё это создаёт пиковые нагрузки, которые нужно учитывать заранее.
• Сколько диска реально потребуется не «сейчас», а через 3–6 месяцев. Рост файлов, логов и базы — вещь предсказуемая, если присмотреться.

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

Как рассчитать CPU на VPS

CPU для VPS нельзя оценивать по принципу «чем больше ядер, тем лучше». Важны два момента: сколько параллельных задач должен обслуживать сервер и насколько каждая из них вычислительно тяжела. Отдача статики — это почти нулевая нагрузка на процессор, а генерация отчётов или обработка изображений — совсем другое дело.

Когда CPU упирается первым

• Динамические страницы на WordPress, Bitrix, Laravel или Node.js почти всегда упираются в CPU, особенно когда PHP или JavaScript выполняются синхронно на каждый запрос.
• Интернет-магазин с фильтрами, корзиной и личным кабинетом — это постоянные обращения к базе, генерация HTML и обработка AJAX-запросов.
• API с большим числом запросов в секунду, особенно если там авторизация, валидация и сложная бизнес-логика.
• Фоновые задачи: очереди, крон, генерация превью, импорт данных. Всё это ест процессорное время в фоне, и если его не хватает, основные запросы начинают конкурировать с ними.
• Сборка проектов, CI, аналитические скрипты — типичный случай для dev-серверов или виртуалок, где крутятся Jenkins, GitLab Runner и подобные инструменты.

Практический подход к расчету CPU

Ориентируйтесь не на мифический «один сайт = одно ядро», а на характер нагрузки. Вот практичная стартовая сетка:

Если VPS будет совмещать несколько ролей — веб-сервер, база, кеш, очереди — берите CPU с запасом. В пике загрузка процессора не должна стабильно превышать 60–70%, иначе вы уже на грани. Это правило из практики: как только load average начинает превышать количество ядер в полтора-два раза, пользователи замечают деградацию.

Как понять, что CPU маловат

• страницы открываются рывками;
• растет время ответа, хотя память еще свободна;
• нагрузка процессора постоянно держится высокой;
• в пике появляются очереди задач и таймауты;
• сервер не падает, но «думает» перед каждым действием.

В терминале это видно по load average, который стабильно превышает количество ядер. Дополнительно можно смотреть на % steal в top — если он постоянно выше 5–10%, значит, виртуалка страдает от соседей по хосту.

Важный нюанс про виртуализацию

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

Как рассчитать RAM

Оперативную память на VPS недооценивают чаще всего. Если CPU можно кратковременно перегрузить, то при дефиците RAM система начинает сбрасывать данные в swap на диск, и отклик мгновенно деградирует. Это как пытаться работать с файлом подкачки на HDD вместо оперативки — медленно и больно для всех процессов. В реальности даже быстрый NVMe-диск в роли swap медленнее RAM в десятки раз.

Из чего складывается потребление RAM

• сама операционная система;
• веб-сервер (nginx, Apache);
• база данных (MySQL, PostgreSQL);
• кеши (Redis, Memcached);
• сами приложения;
• фоновые воркеры;
• буфер файлового кеша.

Причём Linux активно использует свободную память под кеш — это нормально, и не стоит паниковать, видя, что «вся память занята». Если вы видите в top, что used почти 100%, но при этом нет swap — это, скорее всего, работает кеш, который система отдаст приложениям при необходимости. Реальная нехватка проявляется именно в использовании swap.

Базовая логика расчета

Для старта удобно опираться на такие ориентиры:

• 1–2 ГБ — минимальный VPS для очень простых задач: статический сайт, VPN, тестовый стенд;
• 2–4 ГБ — небольшой сайт, тестовый сервер, лёгкий проект;
• 4–8 ГБ — рабочая конфигурация для CMS, небольшого магазина, нескольких сервисов;
• 8 ГБ и выше — если есть база данных, кеширование, несколько контейнеров, очереди или заметный трафик.

Помните: лучше стартовать с запасом, чем через месяц экстренно апгрейдиться. Миграция на другой тариф — это всегда риск и время простоя.

Сколько RAM закладывать под типовые сценарии

Это не догма, а стартовые рекомендации. Например, для WordPress с кучей плагинов и активным кешированием 4 ГБ может оказаться впритык, если база раздуется или пойдут фоновые задачи. Реальный расход зависит от конкретной конфигурации.

Как не ошибиться с памятью

• Не забирайте RAM «в ноль». Нужен запас под пики и кеш.
• Не путайте свободную память с бесполезной. Linux активно использует память под кеш, и это нормально.
• Если swap начал регулярно использоваться, это не «мелочь», а признак тесного тарифа.
• База данных почти всегда любит память больше, чем кажется на старте — особенно при росте индексов и числа одновременных соединений.

Типовые ошибки

• берут 1 ГБ «для экономии», а потом ставят туда CMS, БД и панель — и удивляются, что всё тормозит;
• не учитывают фоновые воркеры, которые съедают память в фоне;
• забывают про кеширование и tmp-файлы, которые тоже требуют место в RAM;
• смотрят только на среднюю загрузку, игнорируя пиковые всплески.

Как рассчитать диск

Ошибки с диском обходятся дороже всего. Нехватка места проявляется внезапно, и последствия неприятные: от отказа записи логов до повреждения базы данных, если том заполнится под завязку. У меня был случай, когда на VPS закончилось место во время ночного бэкапа — база просто отказалась писать, и хорошо, что обошлось без потери данных.

Что занимает место на VPS

• операционная система;
• пакеты и обновления;
• база данных;
• файлы сайта;
• логи (часто растут без контроля);
• кеши;
• резервные копии;
• временные файлы;
• пользовательские загрузки.

Часто забывают про старые ядра после обновлений, неудаляемые логи ротации или мусор от предыдущих версий приложений. Всё это суммарно съедает гигабайты.

Формула расчета диска

Удобная рабочая схема:

диск = ОС + приложение + база + логи + бэкапы + uploads + запас 20–30%

Запас обязателен. Если диск забит под 100%, проблемы начинаются не постепенно, а резко: перестают писаться логи, ломаются обновления, база может работать нестабильно. Лучше держать свободное место, чем рисковать целостностью данных.

Практическая оценка по сценариям

Эти цифры — ориентир. Если у вас медиасайт с большим количеством изображений или видео, сразу смотрите в сторону 150+ ГБ, даже если сейчас контента немного — он растёт быстрее, чем кажется.

Что часто забывают при расчете диска

• логи растут быстрее, чем кажется, особенно если не настроена ротация;
• базы данных увеличиваются неравномерно — скачками при импортах, добавлении индексов или архивации;
• бэкапы могут занимать больше места, чем сама рабочая копия, если хранится несколько поколений;
• кеши CDN, миниатюры изображений и временные файлы съедают гигабайты незаметно;
• обновления пакетов требуют свободного пространства для распаковки — обычно в 2–3 раза больше размера пакета.

Сколько свободного места держать

На VPS лучше оставлять не меньше 20–30% свободного диска. Для баз данных и проектов с активными логами это особенно важно. Практичный минимум — 20–30% свободного места. Для проектов с базами данных и активным логированием старайтесь держать запас ближе к верхней границе. Это даст время среагировать до того, как диск забьётся полностью.

Пошаговый алгоритм расчета VPS

Когда вы разобрались с профилем нагрузки, можно переходить к конкретным расчётам по шагам.

Шаг 1. Описать нагрузку

Сформулируйте полный список того, что будет крутиться на VPS: веб-сервер, база данных, панель управления, VPN, контейнеры, задачи по расписанию, бэкапы. Чем детальнее, тем точнее расчёт.

Шаг 2. Выделить главный ресурс-ограничитель

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

Шаг 3. Посчитать базу по каждому ресурсу

Используйте базовые ориентиры:

• CPU — от 1 до 4 vCPU;
• RAM — от 2 до 8 ГБ;
• диск — от 30 до 100 ГБ в зависимости от данных.

Это отправная точка, которую дальше корректируем под специфику.

Шаг 4. Добавить запас

• CPU: +20–30% на пики;
• RAM: +30–50% к минимальному расчету;
• диск: +20–30% свободного пространства.

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

Шаг 5. Проверить рост на 3–6 месяцев

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

Как проверить расчет на практике

После запуска сервера важно не расслабляться, а наблюдать за ключевыми метриками. Только реальные данные покажут, насколько верен был расчёт.

Минимальный набор наблюдений

• загрузка CPU в обычное и пиковое время;
• использование RAM и наличие swap;
• заполнение диска;
• рост логов;
• время ответа приложений;
• поведение базы данных.

Для этого достаточно стандартных утилит: top, htop, iostat, df, sar. Настроенный мониторинг (например, Prometheus + Grafana) даст ещё больше наглядности.

Когда пора увеличивать ресурсы

• CPU регулярно держится выше 70% в рабочее время;
• RAM почти всегда занята, а swap используется постоянно;
• диск заполнен более чем на 80%;
• сайт начинает тормозить именно в рабочие часы;
• база данных замедляется без явной причины;
• фоновые задачи не укладываются по времени.

Готовые ориентиры по типам проектов

Это практичная стартовая сетка, а не истина в последней инстанции. Конкретные цифры зависят от кода, плагинов, базы и профиля запросов. Всегда проверяйте на реальной нагрузке.

Чек-лист перед покупкой VPS

• понятен тип нагрузки;
• известны критичные процессы;
• учтены пики;
• заложен запас по CPU;
• заложен запас по RAM;
• диск рассчитан с учетом логов, БД и бэкапов;
• есть план апгрейда;
• выбран SSD или NVMe, если проект чувствителен к скорости;
• понятно, где и как будет мониториться нагрузка.

Короткий вывод

Ресурсы VPS подбираются не по субъективным ощущениям, а от реального профиля нагрузки. CPU отвечает за вычисления, RAM — за скорость и стабильность процессов, диск — за данные, логи и запас прочности. Если оценивать все три компонента в комплексе и закладывать резерв, сервер будет работать предсказуемо, без перманентной борьбы с лимитами и срочных переездов.

FAQ

Какой VPS взять для старта, если проект еще маленький?

Для простого сайта или тестового стенда обычно хватает 1–2 vCPU, 2 ГБ RAM и 30 ГБ диска. Если планируется CMS и база данных, разумнее стартовать с 2 vCPU и минимум 4 ГБ RAM — это избавит от мучительного апгрейда через пару недель.

Что важнее при выборе VPS: CPU или RAM?

Зависит от того, что делает сервер. Сайты на CMS чаще упираются в память, а фоновые задачи и вычисления — в процессор. Однозначного ответа нет: узкое место выявляется только после анализа реальной нагрузки. Поэтому сначала профилируйте, потом выбирайте.

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

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

Почему диск нужно брать с запасом, если данных сейчас мало?

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

Сколько свободного места должно оставаться на диске?

Ориентируйтесь на 20–30% свободного места. Для баз данных и проектов с интенсивным логированием держите запас ближе к 30% — это даст время среагировать на внезапный рост.