Как выбрать VPS: пошаговый разбор под задачу

Совет "берите с запасом" - это не метод, а способ переплатить за простой. Разберём, как выбрать VPS под конкретный проект по-другому: сначала смотрим, что на сервере будет работать, потом считаем, сколько это ест по процессору, памяти и диску, разбираем строчки "порт 200 Мбит/с" и "безлимит" и проверяем машину замером в первый час после оплаты. VPS здесь - арендованная виртуальная машина с полным доступом (root), которая ведёт себя как отдельный сервер, хотя железо делит с соседями. Команды - для Ubuntu 22.04, 24.04 и 26.04; на Debian то же, отличия отмечены.

Коротко. Отталкивайтесь от нагрузки, а не от таблицы тарифов. Статике и лендингу хватает 1 ГБ памяти и 1 ядра; WordPress и небольшому магазину - 2-4 ГБ и 2 ядра; нескольким сервисам в Docker или нагруженной базе - от 8 ГБ и 4 ядер. Диск - SSD; для тяжёлой случайной нагрузки лучше NVMe, HDD только под архивы. Виртуализация - KVM: полноценная виртуальная машина со своим ядром и совместимостью с обычным Linux-стеком; гарантии по CPU, памяти и диску и апгрейд без переустановки задаёт не сам KVM, а тариф и политика провайдера - это проверяют замером. "Порт 200 Мбит/с" - это ширина канала (на пределе порядка 90 ГБ в час), "безлимит" - объём не тарифицируется, но скорость всё равно упирается в порт. После аренды прогоните fio, sysbench и iperf3 по 5-10 раз и смотрите на диапазон.

Как выбрать VPS: начните с того, что будет работать на сервере

Чтобы понять, как выбрать VPS, начните не с цен, а с инвентаря нагрузки: выпишите всё, что будет работать на сервере одновременно. Обычный сайт на CMS - это не один процесс, а стопка: веб-сервер, интерпретатор (PHP-FPM, Node.js, Python), база данных, часто кеш (Redis), фоновые задачи по расписанию. Каждый держит память, даже когда на сайт никто не заходит. Конфигурация должна покрывать сумму этих аппетитов в пик посещаемости, а не среднее за сутки.

Дальше развилка. Один проект на сервер - считать просто, апгрейд предсказуемый. Всё в одну коробку (несколько сайтов, бот, база, мониторинг) - дешевле в моменте, но нагрузки складываются и мешают друг другу: тяжёлый запрос к базе одного сайта роняет отклик остальных. Для проекта, от которого зависят деньги или клиенты, держите его отдельно; складывать всё вместе нормально для пет-проектов и стенда.

Если путаетесь в терминах "VPS", "VDS", "облако" и "выделенный сервер" - это отдельный разбор. Здесь важно одно: тип виртуализации и гарантии ресурсов, а не буквы в названии тарифа.

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

Собрать конфигурацию под любую из этих строк можно на странице Тарифы VPS: линейка одинаковая на всех локациях (от 1 vCPU / 1 ГБ / 20 ГБ SSD до 16 / 64 / 500), различаются точка присутствия и цена. Ниже - та же таблица со ссылкой на подходящий тариф; цены даны по линейке Швеции как ориентир. Локацию выбирайте по географии аудитории: новые площадки в ЕС - Швеция, Финляндия, Франция - идут с каналом 200 Мбит/с.

Сколько ядер CPU нужно вашему проекту

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

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

Есть ли запас, подсказывает load average - среднее число процессов, которые считают на процессоре, стоят к нему в очереди или застряли в ожидании диска (состояние D). Три числа - за 1, 5 и 15 минут. Смотрим их и число ядер:

nproc
uptime

• nproc - число доступных vCPU; uptime в конце строки даёт три числа load average.

Эвристика: если средний load average держится ниже числа ядер, процессору есть куда расти. Это эвристика, а не закон - load включает и процессы в состоянии D, поэтому высокий load сам по себе не значит "мало процессора". Сверьте с распределением времени в top:

top

• Строка %Cpu(s): us - ваш код, sy - ядро, wa - ожидание ввода-вывода, st - время, "украденное" гипервизором в пользу соседей.
• Высокий load, но us+sy низкие, а wa большое - вы упираетесь в диск, ядра не помогут.
• устойчиво высокий st, совпадающий по времени с просадками, значит, что VM регулярно недополучает процессорное время на уровне гипервизора. Частая причина - contention или переподписка хоста, но по одному st точную причину не установить; 10% здесь - пример заметного значения, а не порог диагноза.

Сколько RAM брать и как это посчитать

Нехватка памяти роняет сервис мгновенно, поэтому считать её лучше по факту. Измерьте пиковое рабочее потребление под реальной нагрузкой и оставьте запас на всплески; как стартовую прикидку берут +30-40%, но единого процента для всех проектов нет. "Простаивающей" памяти при этом не бывает: свободную RAM Linux сам отдаёт под кеш файловой системы (недавно прочитанные файлы), поэтому ориентируйтесь на available, а не на free. На 1 ГБ статика живёт спокойно, а WordPress будет балансировать на грани swap при первом наплыве - берите 2 ГБ.

free -h

• Колонка available - сколько реально можно занять, не залезая в swap; смотрите на неё. Занятый Swap сам по себе ещё не дефицит: ядро может держать в нём давно вытесненные холодные страницы даже когда RAM уже освободилась. Тревожит связка - низкий available вместе с активной подкачкой (ниже).

Проверьте, не убивало ли ядро процессы из-за нехватки памяти. OOM killer - механизм ядра Linux, который при исчерпании памяти завершает один из процессов; сработать он может и по лимиту контейнера, когда на хосте память ещё есть.

sudo journalctl -k | grep -iE 'out of memory|killed process'

• Есть такие строки - памяти не хватало и сервис падал. Пусто - пока спокойно. Если journal без истории, то же в sudo dmesg -T | grep -i oom.

И посмотрите, идёт ли подкачка прямо сейчас:

vmstat 1 5

• si и so - скорость подкачки в память и из памяти (КБ/с). Устойчивые ненулевые значения одновременно с низким available и просадкой производительности - вот это уже давление по памяти, добавляйте RAM. Разовые всплески при запуске сервисов - норма.
• swpd - сколько swap занято. Первый отчёт vmstat - средние с загрузки, смотрите со второй строки.

Какой диск выбрать - NVMe, SSD или HDD

Диск с точки зрения сервера описывают два числа. IOPS - количество операций ввода-вывода в секунду. Задержка (latency) - сколько ждём одну операцию. Для базы данных и раздачи множества мелких файлов важны оба: это тысячи разрозненных мелких чтений и записей, а не один линейный поток.

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

По объёму: система плюс типовой сайт - 5-15 ГБ, дальше растут база, загрузки, логи. Резервные копии держите не на том же диске - он может умереть вместе с ними.

Когда сайт начинает тормозить, причина нередко не в коде, а в диске: под нагрузкой всё упирается в него. Смежная тема - разбор частых ошибок веб-сервера, где 502 и 504 тоже нередко оказываются нехваткой ресурсов. Как измерить диск - в разделе про проверку.

KVM или OpenVZ: виртуальная машина против контейнера

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

KVM - полноценная виртуальная машина: гипервизор эмулирует железо, у вас своё ядро Linux и совместимость с обычным Linux-стеком. Можно менять параметры ядра (sysctl), поднимать свой swap, ставить любой дистрибутив, гонять Docker и WireGuard без сюрпризов. Но сам по себе KVM не гарантирует выделенные CPU, RAM и IOPS: он поддерживает overcommit процессора и памяти и memory ballooning, так что честность распределения ресурсов - это вопрос конфигурации и политики провайдера, а не типа виртуализации.

OpenVZ - контейнерная виртуализация: все контейнеры на хосте делят одно ядро. (Сам проект OpenVZ сейчас включает и KVM-виртуалки, но в тарифах "OpenVZ" обычно означает именно контейнер.) Память часто настраивается как гарантированный минимум плюс burst, пока на хосте есть свободное - конкретика зависит от провайдера. Часть параметров ядра недоступна, версию ядра вы не выбираете.

Для предсказуемости и совместимости берите KVM. OpenVZ оправдан только заметной экономией на совсем простых задачах. "VPS" и "VDS" на практике одно и то же - аренда виртуальной машины с root; "VDS" в рекламе иногда намекает на аппаратную виртуализацию, но термин никто не стандартизовал.

Что значат "порт 200 Мбит/с" и "безлимит"

"Порт 200 Мбит/с" - это ширина канала, потолок скорости в моменте, а не месячный лимит. 200 мегабит в секунду - это 25 мегабайт в секунду. На пределе за час так проходит порядка 90 ГБ, за месяц круглосуточной полки - порядка 65 ТБ. Цифры округлённые (зависит от того, считать в гигабайтах или гибибайтах), но порядок такой.

"Безлимитный трафик" (он же unmetered) означает, что объём переданных данных не тарифицируется - счёта за лишние терабайты не будет. Но скорость всё равно ограничена портом, и у многих провайдеров при круглосуточной полке действует политика честного использования: попросят перейти на тариф с гарантированной полосой или мягко срежут скорость. Разовые всплески под нагрузкой - это не про неё.

Обычному сайту канал в 100-200 Мбит/с узким местом не станет: страница генерируется дольше, чем передаётся. Ширина канала важна для раздачи крупных файлов, стриминга и выгрузки бэкапов наружу.

Как проверить сервер после аренды

Провайдер обещал ядра, память, быстрый диск и канал. Проверьте это в первый час, пока сервер пустой и его легко поменять или вернуть. Инструменты ставятся одной командой - на минимальных облачных образах их из коробки нет:

sudo apt update
sudo apt install -y fio sysbench iperf3

• Пакеты берутся из стандартного репозитория: на Ubuntu - universe (обычно уже включён), на Debian - main.

sysbench cpu --cpu-max-prime=20000 --threads=1 run

events per second

sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Диск. Случайное чтение-запись блоками 4 КБ - это профиль работы базы данных. Команда создаёт тестовый файл на 1 ГБ и реально пишет на диск, так что нужно свободное место; после теста файл удалите (rm -f randrw.0.0).

fio --name=randrw --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 \
--bs=4k --size=1G --numjobs=1 --iodepth=32 --runtime=60 --time_based \
--group_reporting

• --direct=1 - мимо кеша страниц, чтобы мерить сам диск, а не память.
• --rwmixread=70 - 70% чтения, 30% записи, как у типичной базы под нагрузкой.
• --iodepth=32 - глубина очереди: столько операций "в полёте" одновременно (работает с асинхронным движком libaio).
• libaio обычно ставится автоматически как зависимость fio. Запасной синхронный движок - --ioengine=psync, но только с --iodepth=1: его числа нельзя напрямую сравнивать с libaio на --iodepth=32, это уже другой тест.
• В выводе смотрите read: IOPS=..., write: IOPS=..., среднюю completion latency (clat avg) и блок clat percentiles, особенно строку 99.00th.

Процессор. sysbench считает простые числа до 20000 - чистая нагрузка на CPU без диска и сети.

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

• Смотрите строку events per second. Второй запуск - на всех ядрах ($(nproc) подставит их число); результат должен заметно вырасти относительно одного потока, но точного роста в число vCPU не будет: мешают SMT, turbo boost, тепловые лимиты и планировщик. Если многопоточный результат скачет между прогонами или проседает одновременно с высоким st - это уже повод подозревать contention на хосте.

Сеть. Нужен доступный сервер iperf3 - у провайдера, в том же дата-центре или публичный (публичные часто перегружены и режут скорость). Меряйте до близкого узла: далёкий ограничит скорость задержкой канала, а не вашим портом.

iperf3 -c SPEEDTEST_HOST -p 5201 -t 20
iperf3 -c SPEEDTEST_HOST -p 5201 -t 20 -R

• -t 20 - двадцать секунд теста; -R - обратное направление, скачивание к вам. Итоговые строки sender/receiver - средняя скорость; сравните с обещанным в тарифе.

Реальный отклик. iperf3 и fio меряют железо по отдельности, а пользователь видит сумму - сеть плюс генерацию страницы.

for i in $(seq 1 10); do
curl -o /dev/null -s -w '%{time_total}\n' https://ваш-сайт/
done

• Каждый запуск curl - отдельный запрос с нуля, соединение не переиспользуется, поэтому и гоняем десять раз. Ровные значения - хорошо; скачки в разы - сервер или канал под нагрузкой.

Каждый тест - 5-10 раз, важен диапазон, а не одно число. Конкретные "нормальные" цифры намеренно не привожу: они сильно зависят от поколения железа хоста и от соседей. Ориентир один - то, что обещал тариф, и повторный замер на другой день.

Когда VPS уже не хватает

Решение о переезде принимают по замерам, а не по ощущению "тормозит". Что упёрлись по-настоящему:

• load average стабильно выше числа ядер, и в top видно us+sy под 100%, а не wa;
• available в free -h стабильно низкий, и vmstat показывает устойчивые si/so;
• fio упёрся в потолок IOPS, и он совпадает с лимитом тарифа;
• колонка st в top устойчиво высокая и совпадает по времени с просадками производительности (частая причина - contention или переподписка хоста).

Порядок действий: сначала апгрейд (обычно процессор, память и диск наращиваются без переустановки, с короткой перезагрузкой - если провайдер так настроил), затем - разнести сервисы: база на отдельный сервер, приложение на своём. Выделенный сервер берут, когда нужен весь ресурс физической машины предсказуемо и без соседей: постоянно высокая нагрузка, требования лицензий, тяжёлая база 24/7. Для остального VPS дешевле и гибче.

Частые вопросы

Сколько оперативной памяти нужно серверу?

Статике - 1 ГБ, WordPress или небольшому магазину - 2-4 ГБ, нагруженной базе или нескольким сервисам в Docker - от 8 ГБ. Считайте по пиковому рабочему потреблению с запасом на всплески (как стартовая прикидка - плюс 30-40%, не жёсткая формула); ориентир - available, а не free, так как свободную RAM Linux сам занимает под файловый кеш. Что памяти мало, видно по низкому available вместе с постоянной подкачкой (si/so в vmstat) и по срабатыванию OOM killer - механизма ядра, убивающего процесс при нехватке памяти.

Сколько ядер CPU нужно для сайта?

Одного-двух ядер хватает большинству сайтов на CMS: узкое место обычно не процессор, а диск и база. Больше ядер нужно под постоянную фоновую работу - очереди, перекодирование, сборку, парсинг. Ориентир: если средний load average держится ниже числа ядер, запас есть; сверяйте со строкой %Cpu в top (us, sy, wa).

Что выбрать - VPS или VDS?

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

KVM или OpenVZ - что выбрать?

KVM - полноценная виртуальная машина: своё ядро и совместимость с обычным Linux-стеком, можно менять параметры системы и ставить любой дистрибутив. Гарантии по CPU и RAM и апгрейд без переустановки зависят от провайдера, а не от того, что это KVM. OpenVZ - контейнер, ядро общее с соседями, память часто "плавающая". Для предсказуемости и совместимости берите KVM; OpenVZ оправдан только заметной экономией на совсем простых задачах.

NVMe, SSD или HDD для сервера?

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

Как проверить скорость VPS после аренды?

Диск - fio со случайным чтением-записью блоками 4 КБ, процессор - sysbench cpu, сеть - iperf3 до близкого узла плюс несколько прогонов curl к реальному сайту. Пакеты ставятся одной командой: sudo apt install -y fio sysbench iperf3. Каждый тест запускайте 5-10 раз и смотрите на диапазон, а не на одно число.

Что значат "порт 200 Мбит/с" и "безлимитный трафик"?

200 Мбит/с - это ширина канала, максимальная скорость в моменте; на пределе за час проходит порядка 90 ГБ (цифра округлённая). "Безлимит" значит, что объём данных не тарифицируется, но скорость всё равно ограничена портом, а при круглосуточной полке у многих провайдеров действует политика честного использования. Обычному сайту такого канала хватает с запасом.

Можно ли потом увеличить тариф?

Апгрейд процессора, памяти и диска обычно делается без переустановки системы, с короткой перезагрузкой - если провайдер так настроил (у большинства KVM-хостингов это так). Поэтому на старте берут минимально достаточную конфигурацию и растят её по факту нагрузки. Диск при этом обычно наращивают только вверх, уменьшить его нельзя. У WeaselCloud смена тарифа делается из панели; линейки - на странице Тарифы VPS.

Коротко

• Начинайте с инвентаря нагрузки, а не с таблицы тарифов: сначала что работает на сервере, потом сколько это ест.
• CPU: 1-2 ядра почти всем сайтам на CMS; больше - только под постоянную фоновую обработку.
• RAM: считайте по пиковому рабочему потреблению с запасом на всплески (стартовая прикидка +30-40%); ориентир - available. Постоянная подкачка (si/so) при низком available и срабатывания OOM killer - сигнал добавить память.
• Диск: SSD под рабочую нагрузку, NVMe - для тяжёлой случайной; HDD только под архивы и бэкапы.
• Виртуализация: KVM - своё ядро и совместимость с Linux-стеком; гарантии ресурсов и апгрейд без переустановки зависят от провайдера, не от KVM.
• "Порт 200 Мбит/с" - потолок скорости (порядка 90 ГБ в час), "безлимит" - про то, что объём не считают, а не про скорость.
• После оплаты прогоните fio, sysbench и iperf3 по 5-10 раз; сравнивайте с обещанным в тарифе, а не с ощущением.
• Растите по замерам: у KVM тариф поднимается без переустановки.

Посчитали конфигурацию под свою нагрузку - соберите её на странице Тарифы VPS. Виртуализация KVM, SSD-диски, выбор локации от Швеции и Финляндии до Москвы, апгрейд процессора, памяти и диска потом из панели без переустановки системы. Начните с минимально достаточного и растите по факту замеров, а не по совету "возьми побольше".