Многие SaaS-проекты начинают с одного VPS. Это нормально: быстро, недорого, удобно для MVP, первых клиентов, админки, API, базы данных и фоновых задач. Проблема начинается позже, когда проект уже вырос, но инфраструктура осталась такой же: один VPS, одна база, несколько worker-процессов, cron-задачи, очереди, веб-сервер и всё это конкурирует за один и тот же ресурс.

В какой-то момент владелец видит странную картину: CPU в приложении вроде бы не всегда загружен на 100%, RAM ещё есть, диск не полностью занят, но SaaS начинает отвечать медленно. API периодически зависает, фоновые задачи отстают, база данных то работает нормально, то внезапно тормозит, а пользователи жалуются на нестабильность. Одна из частых причин в виртуальной среде — CPU steal.

CPU steal особенно неприятен тем, что он не всегда выглядит как обычная нехватка процессора. Вы можете оптимизировать код, добавлять кэш, менять настройки PHP-FPM, Node.js, PostgreSQL или MySQL, но задержки всё равно будут появляться. Если VPS находится на перегруженном физическом хосте или ресурсы CPU активно делятся между соседними виртуальными машинами, ваше приложение может ждать процессорное время, даже когда внутри самой VM всё выглядит неочевидно.

Что такое CPU steal простыми словами

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

На VPS вы видите vCPU, но физический процессор остаётся общим ресурсом. Если соседние VM создают высокую нагрузку, гипервизор распределяет процессорное время между всеми. В результате ваш SaaS может ждать CPU, хотя внутри системы вы не всегда увидите классическую картину “процесс съел весь процессор”.

Для сайта-визитки это может быть незаметно. Для SaaS это уже риск, потому что важна не только средняя производительность, а стабильное время ответа. Платный пользователь не оценивает ваш сервер по графику CPU. Он видит, что кабинет открывается медленно, импорт данных зависает, отчёт строится слишком долго, а webhook от внешнего сервиса обрабатывается с задержкой.

Типичные признаки, что SaaS упёрся не просто в VPS, а именно в CPU steal

• API отвечает нестабильно: один и тот же запрос иногда выполняется быстро, иногда заметно дольше.
• Load average высокий, но в приложении нет очевидного процесса, который постоянно держит CPU на 100%.
• Очереди задач начинают отставать без понятной причины.
• Плановые задания, импорты, экспорты, генерация PDF, биллинг или обработка webhook выполняются рывками.
• Проблемы усиливаются в одни и те же часы, хотя ваша собственная нагрузка выросла незначительно.
• В `top`, `vmstat` или `mpstat` видно значение `st` или `%steal` выше обычного.
• После перезапуска сервисов ситуация временно кажется лучше, но потом задержки возвращаются.

Важно не перепутать CPU steal с проблемами приложения. Если у вас медленные SQL-запросы без индексов, swap, забитый диск, плохой код, слишком много воркеров или неправильные настройки базы данных, dedicated server сам по себе не исправит архитектурные ошибки. Но если задержки коррелируют с высоким `%steal`, проблема уже может быть не только внутри вашего приложения.

Как быстро проверить CPU steal на Linux VPS

На Debian и Ubuntu установите sysstat:

apt update
apt install -y sysstat

На AlmaLinux, Rocky Linux и RHEL-подобных системах:

dnf install -y sysstat

Проверьте текущую картину через `top`:

top

В строке CPU смотрите параметр `st`. Это и есть steal time. Если во время жалоб пользователей или медленной работы приложения `st` заметно растёт, это уже сигнал.

Более удобная проверка через `mpstat`:

mpstat 1 20

Команда покажет 20 измерений с интервалом в 1 секунду. Смотрите колонку `%steal`. Единичные кратковременные скачки ещё не всегда означают проблему. Важна устойчивость и совпадение с реальными задержками приложения.

Дополнительно можно использовать `vmstat`:

vmstat 1 20

В выводе смотрите колонку `st`. Если она регулярно растёт во время тормозов, VPS ждёт процессорное время от гипервизора.

Как интерпретировать значения CPU steal

Универсального порога для всех проектов нет. Для простого сайта даже периодические скачки могут быть незаметны. Для SaaS, API, биллинга, CRM, аналитики, realtime-сервисов и очередей задач даже умеренный CPU steal может давать неприятную задержку.

• 0–2% — обычно нормальная картина для VPS, если нет жалоб на производительность.
• 5–10% — уже стоит смотреть внимательнее, особенно если в это же время растёт latency.
• 10% и выше во время инцидентов — сильный сигнал, что VPS страдает от конкуренции за CPU.
• 20–30% и выше — для production SaaS это уже серьёзный риск, особенно если значение держится не секунды, а минуты.

Главное правило: смотрите не только на цифру, а на связь с симптомами. Если `%steal` растёт одновременно с долгими API-запросами, задержками worker-процессов и жалобами пользователей, это уже не абстрактная метрика, а реальная причина деградации.

Как отличить CPU steal от других проблем

Перед переездом на dedicated server нужно убедиться, что вы не лечите не ту болезнь. Проверьте базовые показатели:

uptime
free -h
df -h
mpstat 1 20
vmstat 1 20
iostat -xz 1 20

Если высокий `%usr`, значит процессор активно использует само приложение. Это может быть тяжёлый код, много PHP/Node/Python/Java-процессов, неоптимальные фоновые задачи или нехватка CPU в целом.

Если высокий `%iowait`, проблема может быть в дисковой подсистеме: база данных ждёт диск, логирование слишком агрессивное, много random I/O, не хватает IOPS или накопитель перегружен.

Если используется swap, сначала разберитесь с RAM. SaaS, который начал активно уходить в swap, будет тормозить даже на хорошем CPU.

Если высокий `%steal`, проблема часто находится за пределами вашей VM: физический CPU занят другими нагрузками на хосте, а ваша виртуальная машина получает процессорное время не тогда, когда оно ей нужно.

Почему простой апгрейд VPS не всегда решает проблему

Логичная первая мысль — добавить vCPU и RAM. Иногда это действительно помогает. Если ваше приложение реально упёрлось в свои процессы, больше vCPU даст прирост. Но если проблема в steal time и перегруженном хосте, увеличение тарифа VPS не всегда гарантирует стабильность.

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

Для SaaS это критично. Пользователю важна предсказуемость: чтобы запросы выполнялись стабильно, очередь не отставала, cron не срывался, база не ловила задержки, а панель управления не зависала в момент пикового использования.

Когда можно остаться на VPS

Переезд на dedicated server не должен быть автоматической реакцией на любые тормоза. VPS всё ещё подходит, если:

• CPU steal низкий и не совпадает с периодами деградации.
• Основная проблема в неоптимальных SQL-запросах, индексах, кэше или архитектуре приложения.
• Проект ещё небольшой и кратковременные задержки не влияют на оплату, SLA и удержание клиентов.
• Нагрузка растёт плавно, а вертикальный апгрейд VPS даёт понятный результат.
• База данных, очередь и приложение ещё не конкурируют жёстко за один и тот же CPU и диск.

В этом случае лучше сначала оптимизировать приложение: добавить индексы, вынести тяжёлые задачи в очередь, ограничить количество worker-процессов, настроить кэш, проверить slow query log, обновить тариф VPS или разделить базу данных и приложение на разные серверы.

Когда SaaS уже пора переносить на dedicated server

Dedicated server становится правильным решением, когда проблема уже не в разовом пике, а в предсказуемости инфраструктуры.

• CPU steal регулярно появляется во время рабочих пиков.
• Пользователи платят за сервис, и задержки начинают влиять на поддержку, возвраты или отток.
• На одном VPS одновременно работают приложение, база данных, очереди, cron, аналитика и фоновые задачи.
• Проекту нужны стабильные CPU-ресурсы, а не “сколько досталось от общего хоста”.
• Нужен быстрый NVMe под базу данных, логи, кэш, очереди или файловое хранилище.
• Требуется больше RAM без постоянной борьбы за память и swap.
• Нужен понятный путь роста: добавить RAM, заменить накопители, вынести базу, собрать RAID, подключить больше дисков или настроить отдельную сеть.

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

Что даёт dedicated server для SaaS

• Выделенный CPU без конкуренции с чужими виртуальными машинами на том же уровне, как у обычного VPS.
• Более предсказуемое время ответа API и панели управления.
• NVMe-накопители под базу данных, очереди, кэш и активные файлы.
• Возможность увеличить RAM под PostgreSQL, MySQL, Redis, ClickHouse, Elasticsearch или другие сервисы.
• Больше контроля над ОС, ядром, файловой системой, RAID, резервным копированием и сетевыми настройками.
• Возможность разделить роли: приложение, база, worker-процессы, monitoring, backup.
• IPMI/KVM для аварийного доступа, если система перестала загружаться или сломалась сеть.

Для SaaS особенно важна не максимальная синтетическая производительность, а стабильность под реальной нагрузкой. Лучше иметь чуть меньший, но предсказуемый ресурс, чем большой VPS, который иногда начинает ждать CPU в самый неподходящий момент.

Минимальный план миграции SaaS с VPS на dedicated server

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

• Соберите метрики на текущем VPS: CPU, steal, RAM, swap, disk I/O, slow query log, размер базы, размер файлов, количество worker-процессов.
• Определите, что именно упирается в ресурс: приложение, база данных, очередь, диск, RAM или внешний API.
• Подберите dedicated server с запасом по CPU, RAM и NVMe, а не “впритык”.
• Сделайте резервную копию базы данных, файлов, конфигов, cron-задач, systemd-сервисов, Docker Compose-файлов и nginx-конфигов.
• Поднимите приложение на новом сервере параллельно со старым.
• Проверьте версии PHP/Node/Python/Java, расширения, переменные окружения, права на файлы и фоновые задачи.
• Снизьте DNS TTL заранее, чтобы переключение домена прошло быстрее.
• Синхронизируйте финальные данные перед переключением.
• Переключите трафик и оставьте старый VPS как временный rollback-вариант.
• После переезда проверьте логи, latency, очереди, cron, webhooks, оплату, email-уведомления и резервные копии.

Что проверить после переезда

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

systemctl --failed
journalctl -p err -n 100
df -h
free -h
mpstat 1 20
iostat -xz 1 20

Проверьте HTTP-время ответа:

for i in {1..20}; do curl -o /dev/null -s -w "%{http_code} time_total=%{time_total}\n" https://example.com/; sleep 1; done

Проверьте фоновые задачи:

systemctl status your-worker-service
journalctl -u your-worker-service -n 100

Если проект работает в Docker Compose:

docker compose ps
docker compose logs --tail=100

Если используется PostgreSQL, проверьте активные запросы:

sudo -u postgres psql -c "SELECT pid, now() - query_start AS duration, state, query FROM pg_stat_activity WHERE state != 'idle' ORDER BY duration DESC LIMIT 10;"

Если используется MySQL или MariaDB, проверьте список процессов:

mysql -e "SHOW FULL PROCESSLIST;"

Частые ошибки при росте SaaS из одного VPS

• Считать, что добавление vCPU всегда решает проблему. Если есть CPU steal, проблема может быть не только в количестве vCPU.
• Держать приложение, базу, Redis, очереди, cron, аналитику и backup на одном маленьком VPS слишком долго.
• Не смотреть `%steal`, `%iowait`, swap и slow query log, а сразу обвинять код или хостинг.
• Переносить SaaS без тестового запуска на новом сервере.
• Не снижать DNS TTL перед миграцией.
• Забывать про фоновые worker-процессы, cron-задачи, webhook, очереди и email-рассылки.
• Покупать dedicated server без запаса по RAM и диску, а потом снова упираться в лимиты через месяц.
• Не настраивать мониторинг после переезда.

Как быстро починить ситуацию, если SaaS уже тормозит

Если проблема происходит прямо сейчас, сначала не делайте резких действий. Не перезагружайте всё подряд, пока не сняли показатели. Иначе вы потеряете следы проблемы.

• Снимите `top`, `mpstat 1 20`, `vmstat 1 20`, `iostat -xz 1 20` во время тормозов.
• Проверьте, нет ли swap и нехватки RAM.
• Проверьте slow query log базы данных.
• Временно уменьшите количество тяжёлых worker-процессов, если они забивают CPU или диск.
• Перенесите тяжёлые cron-задачи на ночное время или отдельный сервер.
• Если `%steal` стабильно высокий и совпадает с деградацией, планируйте перенос на dedicated server или выделенный CPU-тариф.
• Если проблема в диске, смотрите в сторону NVMe, разделения базы и приложения, настройки индексов и уменьшения лишнего логирования.
• Если проблема в RAM, увеличивайте память и убирайте swap-зависимость.

Как HSTQ может помочь с таким переездом

Если SaaS вырос из одного VPS и начал упираться в CPU steal, правильный путь — сначала подтвердить проблему метриками, а потом переносить проект на инфраструктуру с более предсказуемыми ресурсами.

В HSTQ можно подобрать выделенный сервер под SaaS: с выделенным CPU, NVMe-накопителями, нужным объёмом RAM, IPMI/KVM и возможностью дальнейшего апгрейда. Такой вариант подходит, когда проект уже приносит деньги и нестабильность VPS становится дороже, чем нормальная инфраструктура.

Если проект пока не готов к dedicated server, можно начать с VPS/VDS на NVMe, но важно честно смотреть на метрики. VPS хорош для старта и умеренной нагрузки. Dedicated server нужен тогда, когда SaaS уже требует не просто “больше ресурсов”, а стабильного и предсказуемого поведения под нагрузкой.

Перед заказом лучше открыть тикет или написать в Telegram @hstq_hosting и приложить базовые данные: текущий тариф VPS, ОС, стек приложения, размер базы, среднюю и пиковую нагрузку, вывод `mpstat`, `vmstat`, `iostat`, а также описание симптомов. Так инженер сможет быстрее понять, нужен ли dedicated server сразу или сначала достаточно оптимизации VPS, базы данных и worker-процессов.

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