VPS или облачный IaaS в 2026: когда дешёвый сервер перестаёт справляться

У вас нормальный трафик, CPU на 40%, а пользователи жалуются на лаги. Вы идёте проверять и видите, что сервер не падает, метрики на стандартном уровне, но что-то явно не так. Скорее всего, дело в том, как устроен VPS изнутри и что с ним случилось за последние несколько лет.

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

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

Провайдеры это время распределяют через гипервизор. Пока соседи по хосту не нагружены – вы получаете запрошенные ресурсы. Когда все активны одновременно – гипервизор забирает у вас часть процессорного времени на других. В Linux это видно в метрике %st (steal time): она показывает, сколько времени CPU вашей ВМ простаивал, ожидая своей очереди на физическом ядре.

В 2016–2018 году на один физический поток приходилось 4–8 виртуальных CPU. Сейчас нормой у бюджетных провайдеров стало 10–16. Физические ядра стали быстрее, но конкуренция за них выросла пропорционально.

Базовое потребление Linux заметно выросло за последние несколько лет. Ubuntu 16.04 запускалась в 100-150 MB RAM в режиме сервера, а Ubuntu 24.04 при минимальной конфигурации занимает уже 3000-5000 MB ещё до запуска вашего приложения. Официальные рекомендации Canonical для Ubuntu 24.04 – минимум 2 GB RAM для серверной установки.

На VPS с 1-2 GB это означает, что операционная система сразу забирает треть или половину памяти. Под ваше приложение остаётся меньше, чем кажется при выборе тарифа.

Если в 2015 году типичный бэкенд – это PHP-приложение, MySQL и Nginx – умещался в 512 MB, то современный стек выглядит иначе. К приложению добавляются: брокер очередей, сервис кеширования, агент мониторинга, контейнерный рантайм или несколько сервисов в Docker. Каждый компонент занимает память и использует CPU в фоне.

Поэтому, если три года назад ваш проект работал на VPS с 2 GB RAM, а сейчас вы обновили зависимости и добавили пару сервисов – тот же объём памяти уже не даёт той же производительности.

В 2018 году стало известно об уязвимостях Spectre и Meltdown в процессорах Intel и AMD. Патчи, которые закрыли эти дыры, добавили overhead на операции с памятью и системные вызовы. Для обычного веб-приложения замедление было в пределах 5-10%, но для баз данных с большим количеством операций ввода-вывода некоторые тесты показывали падение throughput до 20%.

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

Симптомы: top или htop показывают устойчивую загрузку одного или нескольких ядер на 90-100%. Запросы к приложению уходят в очередь, время ответа растёт пропорционально нагрузке. При этом RAM свободна, дисковая активность минимальна.

Частая причина на VPS – однопоточный код, который упирается в одно виртуальное ядро. В таких случаях добавление второго vCPU не всегда помогает: если код однопоточный, второе ядро просто не задействуется.

Что проверить первым делом: top с сортировкой по CPU, mpstat -P ALL 1 для того, чтобы посмотреть загрузку по каждому ядру отдельно. Если одно ядро стабильно на 100% – проблема в коде или конфигурации, а не в количестве ядер.

Симптомы: в free -h показывает, что RAM занята почти полностью, активен swap. Даже на NVMe своп работает в десятки раз медленнее оперативной памяти, поэтому приложение начинает подвисать.

Что проверить: free -h для общей картины, vmstat 1 5 для активности свопа, smem или ps aux --sort=-%mem для понимания, какой процесс занимает больше всего памяти.

Симптомы: CPU свободен, RAM в порядке, но запросы всё равно медленные. В iostat -x 1 видно, что %util на диске стабильно высокий, await (среднее время ожидания операции) растёт. Это означает, что диск перегружен запросами и не успевает их обрабатывать.

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

Что проверить: iostat -x 1, iotop для определения процесса-виновника. Отдельно стоит проверить %iowait в top – если он регулярно выше 10-15%, дисковая подсистема перегружена.

Для разовой проверки удобен glances – он выводит CPU, RAM, диск и сеть в одном экране. Для постоянного мониторинга подойдёт Netdata: он устанавливается одной командой, работает в браузере и показывает метрики в реальном времени с детализацией до секунды. Оба инструмента доступны в репозиториях стандартных дистрибутивов и работают на любом российском VPS-провайдере без ограничений.

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

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

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

Решается это установкой Redis и настройкой кеширования на уровне приложения. Redis хранит результаты тяжёлых запросов в памяти и отдаёт их без обращения к базе данных. Для WordPress это плагины типа Redis Object Cache, для Laravel – встроенный драйвер кеша, для Django – django-redis. Для статичных страниц дополнительно имеет смысл настроить страничное кеширование. В этом случае сервер отдаёт готовый HTML-файл без выполнения кода вообще.

Apache удобен в настройке, но потребляет заметно больше памяти при параллельных соединениях. Каждый процесс Apache занимает 20–50 MB RAM, и при 50 одновременных соединениях это уже 1–2.5 GB только на веб-сервер. Nginx обрабатывает соединения асинхронно и при той же нагрузке требует меньше памяти.

Если проект сейчас работает на Apache и сервер упирается в RAM, переход на Nginx может решить проблему без смены тарифа. Миграция для стандартного PHP-проекта занимает несколько часов и не требует изменений в коде приложения.

Статические файлы – изображения, CSS, JS – стоит раздавать через CDN. Российские провайдеры предлагают CDN-услуги: Selectel, VK Cloud, Яндекс Cloud. Это снимает с VPS нагрузку по раздаче файлов, которые и без того не требуют серверной обработки.

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

Решение – вынести нагруженные компоненты на отдельные серверы. Чаще всего первой выносится база данных: она требует быстрого диска и достаточно RAM для буферного пула, и изоляция позволяет настроить её параметры независимо от приложения. Следующий кандидат – фоновые задачи: воркеры очередей в Laravel, Celery в Django, любые ресурсоёмкие cron-задачи.

База данных – отдельная точка, которую проверяют в последнюю очередь, хотя именно она чаще всего виновата в медленных ответах. Медленные запросы видно через SHOW PROCESSLIST в MySQL или pg_stat_activity в PostgreSQL. Там же видно, есть ли запросы, которые выполняются секундами и блокируют другие.

Включите лог медленных запросов: в MySQL это slow_query_log = 1 с порогом long_query_time = 1, в PostgreSQL — log_min_duration_statement = 1000. После этого в логах появятся запросы, которые выполняются дольше одной секунды. В этом случае можно добавить индексы по полям, которые участвуют в этих запросах, чтобы сократить время выполнения.

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

Steal time – это процент времени, когда ваш vCPU ждёт физического ядра, которое занято другими виртуальными машинами на том же хосте. Смотреть его можно в top в строке %st или через vmstat 1.

Разовые всплески steal до 20–30% во время общего пика нагрузки на провайдера — это нормально. Если steal стабильно держится выше 10–15% на протяжении нескольких часов в сутки, ваше приложение систематически недополучает процессорное время. Оптимизация кода в этом случае даст меньший эффект, потому что ограничение находится на уровне гипервизора, а не вашего стека.

Если vmstat 1 показывает ненулевые значения в колонках si и so (swap in / swap out) при том, что CPU загружен на 20-30%, у сервера закончилась оперативная память и он начал использовать дисковое пространство как её расширение.

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

Верхняя граница у большинства российских VPS-провайдеров на стандартных тарифах – 8-16 GB RAM. Если приложение уже приближается к этому пределу с учётом роста, апгрейд внутри VPS-линейки даст лишь временное решение.

Конкретный признак: вы мониторите время ответа приложения (через Netdata, Zabbix или простой скрипт с curl) и видите, что при той же посещаемости, что была полгода назад, время ответа стало в полтора-два раза выше.

Если оптимизация стека уже проведена, это говорит о том, что ресурсов физически не хватает на текущий объём работы. Проверьте дополнительно: iostat -x 1 для дискового await (нормальное значение для NVMe – до 1-2 мс, значения выше 10 мс указывают на перегрузку дисковой подсистемы хоста).

Если три и более пункта из списка ниже выполняются одновременно на протяжении нескольких недель – VPS уже не справляется и оптимизация не решит проблему:

• CPU steal стабильно выше 10% в рабочие часы
• Своп активен при CPU ниже 50%
• Время ответа приложения выросло на 50% и выше за последние 3-6 месяцев без роста нагрузки
• Резервное копирование занимает вдвое больше времени, чем полгода назад
• Вы уже на максимальном тарифе VPS у текущего провайдера
• Приложение падает или деградирует при кратковременных пиках, которые раньше проходили без последствий

VPS и облачный IaaS – это виртуальные машины, но с разной архитектурой под капотом. Разница становится важной именно тогда, когда VPS упирается в описанные выше ограничения.

VPS – это виртуальная машина на одном физическом сервере. Провайдер делит ресурсы этого сервера между несколькими клиентами: вам достаётся фиксированное количество vCPU, RAM и дискового пространства. Эти ресурсы привязаны к конкретному хосту.

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

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

Ресурсы выделяются из общего пула. Это означает, что вы можете изменить конфигурацию машины через панель управления или API без перезагрузки и без привязки к тому, что физически доступно на одном хосте. Вертикальное масштабирование (добавить CPU или RAM) и горизонтальное (добавить новые инстансы) происходит значительно быстрее.

Для небольшого проекта со стабильной нагрузкой разница между VPS и IaaS минимальна. Она становится ощутимой в нескольких конкретных ситуациях.

• Сезонные пики нагрузки. Если у вашего проекта есть выраженная сезонность – распродажи, учебные периоды, праздничные кампании – VPS вынуждает вас держать мощности, рассчитанные на пик, весь год. В IaaS вы масштабируете ресурсы под конкретный период и сокращаете их после.
• Требования к доступности. VPS не обеспечивает отказоустойчивость на уровне железа: сбой хоста означает простой. Если проект требует SLA выше 99.5% и простой стоит денег, IaaS с репликацией между узлами кластера закрывает эту задачу на инфраструктурном уровне.
• Микросервисная архитектура. Когда приложение состоит из нескольких независимых сервисов, которые нужно разворачивать, масштабировать и обновлять по отдельности, управлять этим через набор VPS становится трудозатратно. IaaS в связке с Managed Kubernetes позволяет автоматизировать этот процесс.

Если вы дошли до точки, когда VPS уже не справляется и чек-лист из предыдущего раздела сработал, следующий шаг – облачная инфраструктура с нормальным SLA и возможностью масштабирования. Linx Cloud предоставляет IaaS на базе собственных дата-центров уровня TIER III в Москве и Санкт-Петербурге, работает на VMware, OpenStack, а уровнем ниже All-flash СХД и кластера хостов уровня Enterprise с полностью дублированной сетью передачи данных. 

Решение о переезде с VPS на IaaS стоит принимать на основе конкретных метрик, а не ощущения, что что-то работает медленно.

Последовательность ваших действий должна выглядеть так:

1. Сначала диагностика через top, vmstat, iostat.
2. Затем оптимизация стека – кеширование, веб-сервер, индексы в базе данных, разделение сервисов.
3. Если после этого проблемы остались и чек-лист из раздела про симптомы показывает три и более пункта, VPS исчерпал свои возможности для вашей задачи.

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