Как выбрать конфигурацию VPS: сколько CPU, RAM и диска нужно сайту

Почему «побольше цифры» — не стратегия выбора конфигурации

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

Четыре ресурса VPS — процессор, оперативная память, диск и сетевой канал — отвечают за разные части работы сайта, и нехватка каждого из них проявляется по-своему. Прежде чем сравнивать тарифы по цене, полезно понимать, какой именно ресурс отвечает за то, что реально тормозит на сайте — тогда конфигурация подбирается осознанно, а не «с запасом на всякий случай», который просто увеличивает счёт.

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

Виртуализация KVM vs OpenVZ: почему это тоже влияет на выбор

Помимо количества ресурсов, важно, каким способом они выделены виртуальному серверу. KVM (Kernel-based Virtual Machine) — это полноценная аппаратная виртуализация: каждый VPS получает собственное изолированное ядро и гарантированный объём ресурсов, которые физически зарезервированы за ним и не могут быть отданы другому клиенту того же хост-сервера ни при каких обстоятельствах.

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

Практическое следствие для выбора конфигурации: на KVM заявленные в тарифе 2 ядра и 4 ГБ RAM — это гарантированный минимум, который всегда доступен именно вам, а не усреднённое ожидание. Это делает планирование конфигурации по таблицам и метрикам нагрузки предсказуемым — ресурсы ведут себя так, как обещано в тарифе, без скрытой зависимости от того, что происходит на соседних виртуальных машинах.

CPU: сколько ядер и какая частота нужны сайту

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

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

Частота ядра (в гигагерцах) влияет на скорость выполнения одного конкретного запроса, а число ядер — на то, сколько запросов сервер может обрабатывать параллельно. Для типичного сайта на CMS второе обычно важнее первого: два ядра на умеренной частоте почти всегда дадут более стабильную работу под нагрузкой, чем одно ядро с максимальной частотой.

RAM: почему нехватка памяти выглядит как «сервер упал»

Оперативная память — это рабочее пространство для всех процессов сайта одновременно: кэш скомпилированного PHP-кода (opcache), буферы и кэш самой базы данных, память под каждый процесс PHP-FPM, который обрабатывает конкретный запрос. Когда памяти не хватает, операционная система либо начинает использовать медленный своп на диске, либо процессы, которым не досталось памяти, аварийно завершаются — именно это чаще всего проявляется как внезапные ошибки 502 Bad Gateway или 503 Service Unavailable в моменты пиковой посещаемости.

Практический ориентир: 1–2 ГБ достаточно для сайта-визитки или блога на WordPress без тяжёлых плагинов; 2–4 ГБ — комфортный минимум для интернет-магазина среднего размера; для CMS корпоративного уровня вроде 1С-Битрикс с интеграцией в 1С и включённым «Композитным сайтом» разумно закладывать от 4–8 ГБ — подробные требования разобраны в статье «Требования 1С-Битрикс к серверу».

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

Диск: почему NVMe — это не про объём, а про скорость

Разница между HDD, SSD и NVMe — это в первую очередь разница в скорости операций ввода-вывода (IOPS), а не только в объёме или цене за гигабайт. База данных сайта постоянно читает и записывает небольшие порции данных — при высокой нагрузке количество таких операций в секунду становится важнее последовательной скорости чтения большого файла, где разница между типами накопителей не так заметна.

HDD (механический диск) — самый медленный вариант, тысячи операций в секунду в лучшем случае, ощутимые задержки под нагрузкой; для активного сайта уже не подходит и сегодня встречается в основном в бюджетных архивных хранилищах. SSD — на порядок быстрее HDD, комфортен для большинства сайтов среднего размера. NVMe подключается напрямую к шине PCIe в обход традиционного SATA-контроллера и даёт ещё на порядок больше операций в секунду — именно поэтому все актуальные тарифы VPS на современных платформах по умолчанию используют NVMe.

Объём диска стоит считать отдельно от его скорости: 20–30 ГБ обычно достаточно для сайта на CMS с умеренным объёмом медиафайлов, но интернет-магазину с большим каталогом изображений, а также любому проекту, который сам хранит бэкапы на том же диске, стоит закладывать заметно больше — с учётом роста на год-два вперёд, а не только текущего объёма файлов.

Сетевой канал: когда он становится узким местом

Пропускная способность канала (обычно измеряется в Мбит/с) отвечает за то, как быстро сервер может отдавать данные посетителям одновременно. Для типичного сайта на CMS с текстом и умеренным количеством изображений канал редко становится узким местом первым — раньше упрутся CPU или RAM. Ситуация меняется, если сайт активно отдаёт тяжёлые файлы: видео, большие изображения в высоком разрешении, архивы для скачивания, или если через сервер идёт много API-запросов от внешних интеграций.

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

Таблица: рекомендуемые конфигурации по типу проекта

Сайт-визитка или блог с посещаемостью до нескольких сотен визитов в день: 1 vCPU, 1–2 ГБ RAM, 20–30 ГБ NVMe — с запасом хватает даже при умеренном росте контента и трафика.

Интернет-магазин небольшого и среднего размера (WooCommerce, OpenCart, PrestaShop) с посещаемостью в пределах пары тысяч визитов в день: 2 vCPU, 4 ГБ RAM, 40–60 ГБ NVMe — комфортный запас для каталога товаров, корзины и оплаты без просадок в пиковые часы.

Корпоративный портал или магазин на 1С-Битрикс с интеграцией в 1С: от 4 vCPU, от 4–8 ГБ RAM, от 60 ГБ NVMe — с учётом того, что эта CMS требовательнее к ресурсам, чем более лёгкие системы, при сопоставимой посещаемости.

Высоконагруженный проект с заметными пиками (акции, сезонные распродажи, СМИ с непредсказуемым трафиком): от 6–8 vCPU, от 8–16 ГБ RAM, NVMe с запасом по объёму — на этом уровне также стоит рассмотреть балансировщик нагрузки на несколько серверов вместо одного максимально мощного, подробнее в разделе /balancers/.

Self-hosted приложение (например, Nextcloud, GitLab или собственная почта) — требования сильно зависят от конкретного продукта: лёгкие инструменты вроде Uptime Kuma достаточно развернуть на 1 ГБ RAM, а GitLab со всеми компонентами комфортно чувствует себя от 8 ГБ.

Как оценить нагрузку заранее, а не гадать

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

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

Простая прикидочная формула для сайтов на PHP: среднее время генерации одной страницы (обычно от 100 мс до 1 секунды в зависимости от CMS и кэширования) умножьте на ожидаемое число запросов в секунду в пиковый момент — это даёт примерное число одновременно работающих процессов PHP-FPM, каждый из которых занимает от 30 до 100+ МБ памяти в зависимости от CMS и подключённых модулей. Например, 10 одновременных запросов при 60 МБ на процесс — это уже около 600 МБ только под сами PHP-воркеры, не считая MySQL, кэш и системные нужды.

Эта формула даёт лишь порядок величины, а не точный расчёт — реальное потребление зависит от конкретной CMS, плагинов и настроек кэширования. Но даже приблизительная прикидка обычно достаточна, чтобы понять, ближе конфигурация к «сайту-визитке» или уже к «нагруженному магазину», и не полагаться исключительно на общие таблицы рекомендаций.

Признаки того, что текущей конфигурации уже не хватает

Панель мониторинга показывает, что средняя загрузка CPU (load average) стабильно выше числа ядер сервера в рабочие часы — это прямой сигнал, что процессору не хватает мощности обрабатывать текущий поток запросов вовремя, и часть из них начинает откладываться в очередь.

Использование оперативной памяти стабильно близко к 100%, а в логах системы или PHP-FPM появляются записи о нехватке памяти или аварийном завершении процессов (OOM Killer) — это означает, что сервер уже не справляется с текущей нагрузкой без потерь, а не просто «работает на пределе».

Сайт периодически отдаёт ошибку 502 или 503 именно в моменты роста посещаемости (реклама, рассылка, попадание в топ выдачи) — это классический симптом нехватки RAM или CPU под пиковой нагрузкой, даже если в обычное время сайт работает нормально.

Операции с базой данных (поиск по каталогу, оформление заказа, загрузка админ-панели) заметно замедляются при одновременной работе нескольких пользователей, хотя CPU и RAM не выглядят перегруженными, — это указывает на диск как на узкое место, особенно если используется устаревший SSD или HDD вместо NVMe.

Частые ошибки при выборе конфигурации

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

Экономия на типе диска ради лишних гигабайт объёма — на устаревшем SSD или тем более HDD даже мощный CPU и много RAM не спасут от медленных ответов базы данных под нагрузкой; лучше взять NVMe с меньшим объёмом и досчитать место позже, чем наоборот.

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

Игнорирование сетевого канала для проектов с тяжёлым медиаконтентом — если сайт активно отдаёт видео или большие файлы, узким местом может оказаться именно канал, даже если CPU, RAM и диск выбраны с запасом.

Смена конфигурации только в момент, когда сайт уже упал под нагрузкой, а не заранее по показаниям мониторинга, — реактивный подход вместо проактивного. Настроить базовый мониторинг загрузки CPU, RAM и диска сразу после запуска намного дешевле, чем терять посетителей и заказы во время внезапного всплеска трафика, к которому сервер оказался не готов.

Вертикальное и горизонтальное масштабирование: куда расти дальше

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

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

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

Пошаговый алгоритм подбора конфигурации

Шаг 1. Определите тип проекта и его характер нагрузки: статический сайт-визитка, динамический блог, интернет-магазин, корпоративный портал на требовательной CMS или self-hosted приложение — у каждого свой профиль потребления ресурсов.

Шаг 2. Оцените реальную или ожидаемую посещаемость: если сайт уже работает, возьмите фактические цифры из аналитики и текущего мониторинга сервера; если проект новый — ориентируйтесь на прогноз или на похожие проекты в вашей нише.

Шаг 3. Сопоставьте тип проекта и нагрузку с таблицей рекомендаций выше, обращая отдельное внимание на тип диска (всегда NVMe для активного сайта) и объём RAM, который для большинства CMS оказывается более узким местом, чем CPU.

Шаг 4. Возьмите конфигурацию с запасом 30–50% сверх расчётной — это покрывает нормальные колебания трафика без необходимости немедленного апгрейда, но не превращается в переплату за многократный избыток ресурсов.

Шаг 5. После запуска понаблюдайте за реальной нагрузкой в панели мониторинга в течение нескольких недель, особенно в моменты роста трафика, и скорректируйте конфигурацию по факту — увеличить ресурсы VPS значительно проще, чем предсказать нагрузку заранее со стопроцентной точностью.

Как быстро сравнить конфигурации на сайте

Самый быстрый способ подобрать конкретный тариф — воспользоваться конфигуратором на странице /vps/, где можно отфильтровать варианты по числу ядер, объёму RAM, типу диска и локации дата-центра и сразу увидеть актуальную цену. Отдельные страницы с подборками по конкретному порогу ресурсов — например, все конфигурации от 4 ядер или от 8 ГБ RAM — доступны по прямым ссылкам вида /vps/4-cpu/ и /vps/8-gb-ram/.

Если нужно посчитать стоимость не только сервера, но и сопутствующей инфраструктуры — базы данных, объектного хранилища, Kubernetes-кластера — удобнее собрать полную конфигурацию в разделе /calculator/ и увидеть итоговую сумму сразу по всем компонентам.

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

Когда VPS уже недостаточно

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

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

Итог: чек-лист выбора конфигурации

Определите тип проекта и характер его нагрузки, прежде чем смотреть на конкретные тарифы. Отдайте приоритет объёму RAM и типу диска (всегда NVMe) — для большинства сайтов на CMS они становятся узким местом раньше, чем число ядер CPU. Ориентируйтесь на таблицу рекомендаций выше, но берите конфигурацию с запасом 30–50%, а не впритык и не с многократным избытком.

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