Как выбрать тариф VDS: CPU vs RAM, NVMe, трафик, SLA и KVM

VDS давно стал стандартом для проектов, которым тесно на виртуальном хостинге: нужна изоляция, корневой доступ, гибкая конфигурация и предсказуемая производительность. Но «идеального» универсального тарифа не существует: для API важен CPU, для интернет‑магазина — дисковая подсистема и RAM, для медиа — сеть и трафик. В этой статье разберём, как выбрать тариф VDS осознанно: сбалансировать CPU vs RAM, понять, зачем NVMe и какие показатели диска действительно влияют на скорость, как читать условия по трафику и SLA, и почему тип виртуализации (чаще всего KVM) имеет прямое отношение к стабильности и безопасности. Если как раз выбираете площадку — изучите тарифы VDS.

CPU: ядра, частоты и реальная производительность

Производительность CPU в VDS определяется не только количеством «vCPU», но и архитектурой, частотой, поколением процессора и политикой оверселлинга. Два тарифа «4 vCPU» могут отличаться в разы.

Что важно в CPU для VDS

• Поколение и микроархитектура: современные AMD EPYC и Intel Xeon Scalable (Ice/Granite, Milan/Genoa) ощутимо быстрее старых поколений на ядро.
• Частота и турбо: для нагрузок с короткими пиками (PHP‑FPM, Nginx, lightweight API) важна высокая частота и быстрый турбо-буст.
• Количество ядер vs производительность на ядро: базы данных и интерпретируемые языки часто упираются в производительность одного ядра; CI/CD, параллельные парсеры и видео‑транскодирование любят много ядер.
• NUMA и планировщик: на гетерогенных узлах распределение ядер по NUMA‑нодам влияет на задержки к памяти. В рамках VDS это контролируется провайдером, но проявляется в стабильности.

Оценивать «vCPU = ядро» некорректно. vCPU — это виртуальный поток, чья производительность зависит от хоста, гипервизора и оверселлинга.

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

• Высокая RPS на малых ответах (gateway/API, Nginx, Envoy, HAProxy).
• Тяжёлые PHP‑страницы без агрессивного кеша.
• Компиляция, CI/CD, миграции в ORM, индексация поиском.
• Видео/аудио‑транскодирование, генерация изображений, шифрование.

Как прикинуть CPU потребности

• Для PHP‑сайта без большого кеша: ~1 vCPU на каждые 80–150 одновременных запросов средней тяжести.
• Для Node.js API: ~1 vCPU на 400–800 RPS лёгких эндпоинтов или 1 vCPU на 100–200 RPS тяжёлых.
• Для PostgreSQL: минимум 2 vCPU; OLTP‑нагрузка масштабируется почти линейно до 8–16 vCPU, далее — упирается в диск/блокировки.
• Для CI: считайте по параллелизму джобов; 1 vCPU на каждый активный билд‑поток плюс 1–2 vCPU на обвязку.

RAM: сколько памяти действительно нужно

Недостаток RAM бьёт больнее, чем нехватка CPU: ОС начинает свопить, а задержки вырастают лавинообразно. В «выбор тарифа» закладывайте RAM с запасом под кеши и буферы.

Быстрые ориентиры по типам приложений

• Веб на PHP‑FPM: оцените средний RSS дочернего процесса и умножьте на максимум детей (pm.max_children), прибавьте 20–30% на ОС и веб‑сервер. Часто 2–4 ГБ достаточно, для крупных магазинов — 8–16 ГБ.
• Node.js: 512–1024 МБ на процесс — базовый ориентир; для GraphQL/ORM — дополнительно 30–50%. При микросервисах удобно считать «RAM per pod/process».
• PostgreSQL: минимум 4 ГБ на прод, рабочий диапазон 8–16 ГБ. Настройки shared_buffers 20–25% RAM, work_mem аккуратно (умножайте на число параллельных операций).
• Redis/Memcached: объём данных + 20–50% на оверхед/репликацию + AOF/RDB буферы.
• JVM (Java/Kotlin/Scala): Xms/Xmx + метаданные + off‑heap. На прод обычно начинают с 4–8 ГБ на сервис.

Своп на VDS — страховка, а не «расширение памяти». Если нагрузка регулярно упирается в своп — увеличивайте RAM или оптимизируйте.

Диски: NVMe, IOPS и задержки

Переход с SATA SSD на NVMe — это не «чуть быстрее», а другой класс задержек и параллелизма. Для БД и активной записи NVMe часто критичен.

Почему NVMe

• Задержка: у NVMe на порядок ниже латентность, это видно на коротких запросах БД и small‑files IO.
• Параллелизм: очереди NVMe (много очередей и глубокие QD) дают стабильность под конкурентными запросами.
• IOPS: реальные 100k+ IOPS на чтение у NVMe против десятков тысяч у SATA SSD — важно для интенсива.

Какие метрики важны

• IOPS и latency на случайных 4k чтениях/записях (R/RW 70/30) — наиболее приближено к веб/БД.
• Throughput (MB/s) нужен для медиа и бэкапов, но редко ограничивает веб‑БД.
• Устойчивость под смешанной нагрузкой и соседями (noisy neighbor) — отражает качество узла и оверселл.
• Надёжность: RAID, отказоустойчивость и регулярные бэкапы (снимки/снапшоты) — часть картины производительности: восстановление тоже время.

Как тестировать диск

Простые «синтетики» помогут выявить проблемы. Для краткого среза используйте fio со смешанным профилем, а для БД — pg_test_fsync, pgbench, sysbench fileio. Оценивайте прежде всего задержки p99 на малых блоках.

Трафик и сеть: лимиты, p95 и реальная полоса

Условия по трафику различаются: где‑то он безлимитный с Fair Use, где‑то считается исходящий, встречается биллинг по 95‑му перцентилю, иногда — фиксированный пакет ГБ/ТБ. При «выбор тарифа» важно понимать профиль вашей нагрузки.

На что смотреть

• Входящий vs исходящий: чаще лимитируется исходящий (upload к пользователю), входящий — без ограничений.
• Полоса канала (порт): 100 Мбит/с, 1 Гбит/с и выше. Проверяйте, «shared» это порт или гарантированная полоса.
• 95‑й перцентиль: тарифицируется трафик выше p95. Нужен, если у вас нерегулярные пики — экономит деньги, но требует грамотного графика.
• Fair Use: формулировки «чрезмерное потребление» — уточняйте, какие пороги считаются чрезмерными и какие действия предпримут.
• Маршрутизация и пировки: если аудитория в РФ/СНГ, важны локальные пиры и маршруты; для глобальной — приватные аплинки и точки присутствия.

Прикидки по трафику

• Сайт‑контент без тяжёлого медиа: 1–5 ТБ/мес исходящего на 100–300 тыс. визитов.
• Интернет‑магазин с фото: 5–15 ТБ/мес при 300–600 тыс. визитов и каталоге 20–50 тыс. SKU.
• Статическое видео 720p: грубо 0,5–1,5 МБ/с на поток; мгновенный пиковый канал кратно RPS.

SLA: как читать и не разочароваться

SLA — это не только цифра «99.9% uptime», это набор условий: исключения, процедуры учёта простоя, кредиты, окна обслуживания, RTO/RPO для инфраструктурных сервисов.

Проценты простоя в минутах

• 99.9% — до ~43 минут простоя в месяц.
• 99.95% — до ~22 минут.
• 99.99% — до ~4,3 минуты.

Чем выше SLA, тем жёстче должны быть процессы мониторинга, запчастей и дежурств у провайдера.

На что обратить внимание в SLA

• Исключения: аварии аплинков, DDoS сверх мощности, плановые работы и форс‑мажор. Поймите, что именно входит в расчёт аптайма.
• Учёт простоя: по вашим или по внутренним метрикам провайдера? Как подтверждать инциденты.
• Компенсации: размер кредитов, максимальный лимит, на что они распространяются.
• RTO/RPO для хранилищ и бэкапов: время восстановления и допустимая потеря данных.

SLA — это юридическое обязательство, SLO — внутренняя целевая метрика. Ориентируйтесь на SLA, но проверяйте реальный аптайм своим мониторингом.

Тип виртуализации: почему KVM имеет значение

KVM — аппаратная виртуализация с отдельным ядром ОС внутри гостя. В отличие от контейнерной виртуализации, у KVM изоляция сильнее, а совместимость с ядрами и системами — шире. Это влияет на безопасность, стабильность и предсказуемость «производительность/latency».

Что даёт KVM

• Изоляция: собственное ядро, драйверы virtio, независимые namespaces и cgroups — ниже риск влияния соседей.
• Совместимость: любой дистрибутив с собственным ядром, тонкая настройка kernel, eBPF, iptables/nftables и т.д.
• Прозрачные лимиты: vCPU, RAM, диск — управляются гипервизором; меньше «магии» с разделяемыми ресурсами.

Контейнерная виртуализация годится для плотного хостинга однотипных Linux‑проектов, но в качестве VDS для продовых приложений KVM обычно предпочтительнее. Если подыскиваете удобную админ‑панель под VDS, посмотрите сравнение панелей: какую выбрать в 2025.

Оверселлинг и ballooning

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

Как сбалансировать CPU vs RAM в тарифе

Чаще ошибка не в «мало CPU» или «мало RAM», а в дисбалансе. Память без CPU даёт недогруз, CPU без памяти — своп и блокировки. Вот типовые профили.

Веб‑сайт/лендинг с кэшем

• CPU: 1–2 vCPU с высокой частотой.
• RAM: 1–2 ГБ.
• Диск: NVMe, но высоких IOPS не требуется.
• Сеть: 100–200 Мбит/с достаточно.

Интернет‑магазин (CMS + БД)

• CPU: 4–8 vCPU.
• RAM: 8–16 ГБ (PHP‑FPM + Redis + DB‑кеш).
• Диск: NVMe, высокая устойчивость к R/W 70/30.
• Сеть: 1 Гбит/с порт, пакет трафика с запасом.

API/микросервисы

• CPU: 4–8 vCPU для параллельной обработки.
• RAM: 4–8 ГБ на сервис; при JVM — 8–16 ГБ.
• Диск: NVMe для очередей/журналов.
• Сеть: низкая латентность, p95 под нагрузкой стабилен.

Базы данных

• CPU: 8–16 vCPU с высокой производительностью на ядро.
• RAM: 16–64 ГБ, чтобы держать рабочее множество в памяти.
• Диск: NVMe с гарантированной производительностью, RAID.

Чек‑лист выбора тарифа VDS

• Загрузочный профиль: CPU‑bound, memory‑bound, IO‑bound или mixed? От этого зависит приоритет CPU/RAM/NVMe.
• Оценка RAM: расчёт по компонентам (веб, воркеры, БД, кеш) + 20–30% запас.
• CPU: упор на частоту и per‑core для монолитов/БД; на количество ядер для CI/воркеров.
• Диск: NVMe с внятными IOPS/latency и RAID, проверка стабильности под смешанной нагрузкой.
• Сеть: порт и политика трафика (исходящий/входящий, пакет, p95, FUP).
• SLA: цифра аптайма, исключения, метод учёта, компенсации, RTO/RPO.
• Виртуализация: KVM, прозрачные лимиты, умеренный оверселл.
• Бэкапы: наличие снапшотов и оффсайт‑копий, проверка восстановления.
• Масштабируемость: апгрейд «на лету», расширение диска без простоя.
• Мониторинг: доступ к графикам, метрикам, журналам, алертинг.

Примеры расчёта для типовых проектов

Небольшой сайт/блог на CMS

Посещаемость 100–300k/мес, кеширование на стороне CMS + Nginx. Достаточно 2 vCPU + 2–4 ГБ RAM. NVMe — желателен для быстрой инвалидации кеша и обновлений. Трафик — 1–3 ТБ/мес. Важна высокая частота CPU и максимально предсказуемые задержки диска.

Магазин (PHP‑FPM + MySQL/Redis)

RPS 50–150 на пике, каталог 30k SKU. Закладываем 6–8 vCPU, 12–16 ГБ RAM. Redis (1–2 ГБ), PHP‑FPM с pm.max_children 40–60 и средним RSS 100–150 МБ даёт 4–9 ГБ под воркеры; остальное — под MySQL и кеш ОС. NVMe обязателен: latency p99 при записи — ключ. Трафик 7–12 ТБ/мес, порт 1 Гбит/с.

API‑бэкенд (Node.js/Go + PostgreSQL)

Лёгкие эндпоинты, RPS 1k на пике. На фронт — 4–6 vCPU, 6–8 ГБ RAM. На БД — отдельный VDS 8 vCPU, 16–32 ГБ, NVMe. Сеть — стабильная латентность, проверяйте p95 под нагрузкой.

Очереди и обработчики (RabbitMQ/Redpanda + воркеры)

Требуются быстрые NVMe и достаточный CPU для сериализации/компрессии. 8–12 vCPU, 16 ГБ RAM на ноду брокера; воркеры — по профилю задачи (обычно 2–4 vCPU и 4–8 ГБ). Трафик — всплесковый, биллинг по p95 может быть выгоден.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Тестирование до и после запуска

Даже идеальный по описанию тариф может вести себя по‑разному на практике. Мини‑план тестирования:

• CPU: sysbench cpu с контролем стабильности и нагрева (throttling) на длительном прогоне.
• Диск: fio со смешанным профилем 4k/64k, QD 1–16; смотрите latency p95/p99.
• Сеть: iperf3 на несколько потоков, проверка в «ближние» и «дальние» регионы, оценка джиттера.
• БД: pgbench/sysbench oltp с профилем реальных транзакций.
• Нагрузка приложений: wrk/k6 со сценариями, имитирующими реальные запросы и сессии.

Фиксируйте результаты в одно и то же время суток несколько дней подряд — это позволит заметить влияние соседей и оверселлинга. Если планируете перенос продового проекта, пригодится пошаговая инструкция: миграция без простоя.

Масштабирование и апгрейд без боли

VDS хорошо масштабируется вертикально: добавить vCPU/RAM и расширить диск. Дополнительно продумайте горизонтальное масштабирование критичных компонентов: вынесите БД, кеши и брокеры в отдельные инстансы, перед фронтами поставьте балансировщик, держите статику на отдельных нодах. Для минимизации простоев проверяйте возможность онлайн‑апгрейда и live‑resize диска, а также планируйте окна обслуживания.

Итоги

Выбор тарифа VDS — это сопоставление задачи и ресурсов. Процессор выбираем по производительности на ядро или по количеству потоков в зависимости от профиля; память — с учётом реального RSS сервисов и запасом на кеш; диск — NVMe со стабильной задержкой p99 и достаточными IOPS; сеть — по политике трафика и требуемой полосе; SLA — по реальному процессу учёта и компенсациям; виртуализацию — KVM, чтобы получить изоляцию и предсказуемость. Начните с честной оценки нагрузки, протестируйте стенд, заложите запас и мониторинг — и ваш VDS будет держать производительность, которая нужна бизнесу.