VPS/VDS — это не волшебная коробка, а виртуальный сервер, зависящий от железа и рук, которые всё настраивали. Он не гарантирует стабильную производительность «по умолчанию», и даже если параметры на бумаге выглядят одинаково, под капотом могут скрываться как быстрые NVMe-диски и разумная политика CPU-шаринга, так и загруженный хост с дешёвым RAID на HDD и оверселлом в четыре слоя. Я попытаюсь разобрать ключевые факторы, от которых это зависит.

▍ Архитектура виртуализации и CPU

Первое, на что стоит обратить внимание при выборе VDS, — это способ виртуализации. Виртуальные серверы могут работать либо в контейнерах, либо на базе гипервизоров.

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

Гипервизоры (KVM, Xen, VMware и др.), напротив, обеспечивают полноценную виртуализацию. Каждый VDS получает своё собственное ядро и зачастую — эмулируемое оборудование. Это даёт гораздо больше свободы, так как можно запускать и дистрибутивы Linux, и Windows. Повышенная изоляция, больше настроек, но и больше накладных расходов. Например, KVM включает дополнительные уровни управления CPU/IO и требует ресурсов гипервизора.

Так, если один провайдер использует контейнеры, а другой — KVM на таких же параметрах, на контейнерном VDS могут быть лучшие показатели пропускной способности.

При этом важно понимать, что даже если в характеристиках указано что-то вроде «2 vCPU @ 2.0 GHz», реальное быстродействие может сильно отличаться. На это влияют несколько ключевых факторов:

• Физические ядра против виртуальных. На одном сервере может быть больше виртуальных процессоров, чем физических, — так работает оверселлинг. Например, на узле с 8 ядрами можно запустить 16 виртуальных, и тогда каждый виртуальный сервер будет делить ресурсы с соседом. В Linux это проявляется в параметре CPU steal (%st в top или htop). В умеренных значениях (до 3%) это нормально, но если %st стабильно держится выше — скорее всего, узел перегружен.
• Частота и архитектура CPU. Многое зависит и от процессора. Один и тот же «2.0 ГГц» может означать старый Xeon без TurboBoost и с урезанным кэшем — или новый чип с поддержкой AVX, AES, большим IPC и быстрой памятью. Немало зависит от того, как провайдер настроил виртуализацию — если не зафиксированы частоты, ваша машина может «скакать» между ядрами или даже между NUMA-узлами.
• Планирование. Гипервизор распределяет доступ к ядрам по разным политикам. Иногда применяются приоритеты или пиннинг (фиксация vCPU на физические ядра), иногда — общий пул. От того, сколько у хоста ядер, сколько соседей запущено и как распределены vCPU, зависит, попадёт ли ваш поток в очередь ожидания.

Чтобы держать ситуацию под контролем, важно регулярно смотреть на ключевые метрики: загрузку CPU, %st, load average и %wa.

Например, если у VPS 4 ядра, и load avg стабильно держится около 4 — это сигнал, что процессор под завязку. А если при этом ещё и высокий %st — значит, проблема не в вашей нагрузке, а в том, что хост перегружен.

▍ NUMA и память

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

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

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

Некоторые провайдеры иногда прямо указывают в тарифах поддержку vNUMA-aware или гарантию размещения на одном сокете — редкость, но полезный маркер. В большинстве случаев поведение остаётся непрозрачным.

Память — не только про объём, но и про конфигурацию. Если ОЗУ на виртуалке мало, сервисы начинают экономить. В этом случае особенно страдают CMS-сайты и приложения с активной работой с базами.

▍ Диски и подсистема ввода-вывода

Механический HDD даёт лишь десятки мегабайт в секунду и примерно столько же операций ввода-вывода. SSD на SATA уже в разы быстрее — вплоть до сотен мегабайт и тысяч IOPS. А NVMe-накопители поднимают планку ещё выше — пропускная способность измеряется в тысячах мегабайт, а количество операций достигает десятков тысяч. Например, один источник указывает диапазоны: HDD ~50–150 MB/s, SSD SATA ~200–550 MB/s, NVMe SSD ~3000–7000 MB/s.

Один только переход с HDD на SSD даёт прирост производительности на порядок, а на NVMe делает это ещё раз. Когда у одного провайдера под VDS используется SATA SSD, а у другого — NVMe, сайт может «ожить» уже просто за счёт меньших задержек и более широкой шины.

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



Однако не только тип диска влияет на производительность. Даже у SSD многое зависит от контроллера и организации массива. RAID10 на SSD обеспечивает высокую скорость записи и чтения с отказоустойчивостью, RAID5/6 повышает задержки записи.

Ещё один подводный камень — формат виртуального диска. Например, qcow2 (сжимаемые образы) популярен из-за удобства, но он медленнее RAW и если VDS использует qcow2 на внешнем хранилище, то на каждый I/O падает накладная на расжатие/копирование. RAW-образы ближе к железу и работают быстрее, но требуют больше места.

Внешне все эти детали незаметны, но если загрузка сайта идёт с задержкой или база начинает «тупить» при высоких нагрузках — стоит взглянуть в сторону диска. Тут многое могут рассказать метрики вроде %iowait из iostat или тесты fio, ioping.

▍ Сеть и география

Сетевая подсистема также оказывает не меньшее влияние. Даже такие метрики, как TTFB, напрямую зависят от того, как быстро сервер выходит в интернет и насколько стабильно проходит сигнал до пользователя.

Всё начинается с канала: если у хостинга ограниченный аплинк, например, 100 мегабит вместо гигабита, или между дата-центрами проложены узкие магистрали, это сразу чувствуется при нагрузке.

Иногда задержки возникают внутри самого ЦОДа — из-за перегруженных маршрутизаторов или виртуальных сетей, где весь трафик должен пройти через дополнительные уровни обработки. Но даже при идеальных условиях в пределах самого дата-центра не стоит забывать о географии. Сервер в Германии и сервер в Ташкенте с одинаковыми характеристиками будут работать по-разному, если ваш трафик идёт, скажем, из Владивостока.



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

Такие нюансы редко указываются в характеристиках тарифа, но именно они делают одни VDS плавными, а другие — инертными.

▍ Разные типы сайтов — разная скорость

Не только хостинг определяет скорость работы — тип сайта также играет роль.

CMS (WordPress, Tilda и др.) генерируют каждую страницу, выполняя PHP-код и обращаясь к базе данных. Основная нагрузка — на процессор и диск, которая без кэша превращается в удар по ресурсам. Чуть сложнее история с фреймворками вроде Laravel или Symfony — это тоже PHP, но зачастую более модульное. Библиотеки и ORM могут потреблять CPU и память, но как и с CMS, помощь даёт кэш запросов и опкод-кэш.

SPA (React/Vue на фронтенде + API на бэкенде) — другая история. Фронтенд в таких проектах, как правило, состоит из статических файлов — они грузятся через CDN или напрямую с Nginx и почти не нагружают CPU. Основная нагрузка падает на бэкенд, поэтому API должен быстро отдавать JSON-ответы, обращаться к базе или Redis, а иногда проводить расчёты. То есть тут важны и CPU (обработка запросов), и диск/сеть (если кэши лежат отдельно).

А вот e-commerce (интернет-магазины) — одна из самых тяжёлых категорий. Много динамики и много БД-запросов, поэтому даже с агрессивным кэшированием такие сайты загружают и процессор, и диск, и оперативку. Здесь критичен каждый компонент инфраструктуры.

▍ На что смотреть при выборе VPS/VDS

Итак, при выборе провайдера и сервера обратите внимание на:

• CPU. Узнайте, сколько vCPU обещает провайдер и как они распределены, сколько на самом деле физических ядер, являются ли vCPU «выделенными» или делятся с другими, какая архитектура CPU. Если есть возможность, выясните политику оверсабскрайба — низкая цена без гарантий обычно означает высокую конкуренцию за CPU.
• Память. Спросите, сколько RAM выделено и гарантировано. Проверьте, что заявленные 8 ГБ действительно для вас, и не забудьте объём памяти соотнести с задачами сайта (MySQL, кэши, FPM-пулы).
• Тип накопителя (HDD/SSD/NVMe). Провайдеры часто указывают просто «SSD», но нужно уточнить это SATA-диск, PCIe NVMe или даже сеть. Если есть гарантия IOPS или bandwidth — отлично. Если нет, надо тестировать, например, запустить fio или хотя бы dd.
• Сеть. Уточните скорость сетевого интерфейса и ограничения по трафику и убедитесь, что нет «притормаживания» в вашем пуле.
• Архитектура виртуализации. Если нужна изоляция и гибкость ОС — берите KVM/Xen, если важна скорость и вы доверяете одному ядру — контейнеры.
• Оверселл. Обычно провайдеры это не афишируют, но на low-end VPS он очень высок. Посмотрите, одно и то же железо — чаще 1:1 или 1:2?
• Дополнительные условия. Уточните условия резервного копирования, snapshot’ов и мониторинга. Иногда на пакетах с экономией есть пункты «бекапы не ежедневные» или «нет гарантии быстрого развертывания».

И не забывайте про бенчмарки. Они полезны для начальной оценки, но при переносе сайта лучше прогонять нагрузку, максимально приближенную к боевой. Проверяйте каждый слой, тестируйте нагрузку и следите за CPU% (user, system), %wa, %st, свободной памятью и скоростью дисков.

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

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

▍ Одинаковых VDS/VPS не бывает

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

При выборе VDS/VPS анализируйте весь стек: от ресурсов (число ядер, тактовая частота, NUMA) до I/O (тип и скорость дисков), от сети до того, как настроено ваше ПО (FPM, кеши, веб-сервер).

Шаблон «добавил RAM — стало быстрее» работает не всегда. Если система висит на очередях CPU или умирает на медленных дисках, никакая память не спасёт.

Короче, читайте документацию провайдера, спрашивайте техподдержку, сравнивайте реальные тесты. Особенно важны характеристики — честный провайдер обычно указывает гарантированные CPU, I/O и RAM, и чем меньше тут звёздочек и «пометок», тем лучше. Если о чём-то забыл сказать, дополняйте в комментариях.

© 2025 ООО «МТ ФИНАНС»

Telegram-канал со скидками, розыгрышами призов и новостями IT ?