Пять признаков, что пора на выделенный сервер, и один — что дело не в железе

MAATRIX

«Сервер тормозит — надо брать помощнее» звучит логично, но именно эта логика чаще всего приводит к тому, что деньги потрачены, а проблема осталась на месте. Ниже — пять объективных признаков, что вы действительно упёрлись в физические ресурсы VPS и выделенный сервер оправдан, и один признак-ловушку, который выглядит точно так же, но лечится не железом.

Нагрузка держится высокой не только в пик, а постоянно

Первый и самый очевидный сигнал — не разовый всплеск, а стабильно высокая загрузка CPU и памяти, которая не спадает даже в непиковые часы. Разница принципиальна: всплеск на 5-10 минут в момент рекламной кампании или ночного бэкапа — это нормальная работа системы под редкой нагрузкой, с которой справится и текущий тариф с запасом на пик. А вот загрузка, которая держится на высоком уровне круглые сутки, включая глубокую ночь, когда пользователей почти нет, — это уже не всплеск, а фактический потолок мощности, который сервер отдаёт постоянно.

Смотреть на это стоит не по одному снимку top, а по истории за неделю-две — из Zabbix, Netdata, Grafana или даже штатных графиков панели хостинга. Разовый пик ни о чём не говорит, а вот медиана загрузки за представительный период — говорит многое.

# Быстрый снимок текущей нагрузки по ядрам
mpstat -P ALL 1 5

# То же через sar, если собирается история (пакет sysstat)
sar -u 1 10

# Долгосрочная картина — через uptime load average
uptime

Ориентир, а не жёсткое правило: если медиана загрузки CPU за неделю держится выше 70-80% с учётом ночных часов, а память постоянно в свопе или на грани OOM — вы не эпизодически задеваете потолок, а живёте на нём. У каждого проекта своя чувствительность к запасу, поэтому цифру стоит воспринимать как ориентир для собственных наблюдений, а не как универсальный порог.

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

Steal time растёт — гипервизор физически не может дать больше

Второй признак специфичен именно для виртуализации и не имеет отношения к вашей собственной нагрузке. Steal time (%st в выводе top и vmstat) — это доля времени, когда вашей виртуальной машине было нужно процессорное время, но гипервизор отдал физическое ядро другой виртуалке на том же хосте. Подробный разбор механики этой метрики и того, как её мерить правильно, — в статье steal time: как понять, что сосед по железу ест ваш процессор, здесь коротко о том, почему это признак именно перехода на выделенный сервер, а не апгрейда тарифа.

Ключевое отличие steal time от обычной загрузки: это не то, что делает ваш процесс, а то, чего физический хост ему не дал сделать. Если steal time регулярно ненулевой и растёт месяц за месяцем без изменений в вашей собственной нагрузке — это значит, что физический хост, на котором стоит ваш VPS, продан слишком плотно, и провайдер не может выдать вам больше ресурсов ни на каком тарифе этого хоста. Апгрейд до топового тарифа на том же переполненном железе почти ничего не изменит: соседи по-прежнему будут отъедать такты процессора.

# Колонка st в vmstat — доля украденного процессорного времени, в процентах
vmstat 1 5

Отличить это от собственной нагрузки просто: если внутри VM загрузка вашего процесса (us + sy в top) низкая, а st заметный и стабильный — проблема не в вас. Единственное системное решение — либо переезд на другой хост того же провайдера (что не гарантирует результата надолго), либо выделенный сервер, где над вами физически нет других арендаторов и делить процессорное время не с кем.

Экономика: сумма нескольких VPS уже сравнялась со стоимостью выделенного сервера

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

Посчитать это стоит явно, а не на глаз: сложите ежемесячную стоимость всех виртуальных машин, которые обслуживают один проект, и сравните с ценой одного выделенного сервера сопоставимой суммарной мощности (ядра, память, диск). Методику такого сравнения, включая то, что часто забывают учесть — простой при переезде, лицензии, трафик, — подробно разбирает статья сколько стоит апгрейд сервера против нового сервера.

Экономика смещается в пользу выделенного сервера по двум причинам одновременно. Во-первых, у облачных тарифов ступенчатое ценообразование: переход на следующий уровень мощности часто даёт прирост ресурсов непропорционально приросту цены — грубо говоря, вдвое больше ядер может стоить больше чем вдвое дороже. Во-вторых, несколько виртуалок — это несколько «накладных расходов»: дублирующиеся системные ресурсы на каждую ОС, сетевые задержки между инстансами, сложность синхронизации данных между ними, отдельные бэкапы для каждой. Один физический сервер с той же суммарной мощностью этих накладных расходов не несёт.

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

Потребность в специфичном железе, которого нет в тарифной сетке облака

Четвёртый признак — не про количество ресурсов, а про их конкретные характеристики. Облачные тарифы и VPS-планы устроены как заранее нарезанные пакеты: набор ядер, объём памяти, тип диска из ограниченного списка. Если вашей задаче нужна конкретная конфигурация, которой в этой сетке просто нет, ни один апгрейд тарифа её не даст — потому что дело не в объёме, а в наборе доступных опций.

Типичные примеры такой потребности:

• Гарантированные IOPS и предсказуемая задержка диска. На VPS диск обычно сетевой (Ceph, аналоги) или локальный, но общий для нескольких арендаторов хоста. Если приложению нужен NVMe в RAID10 с предсказуемой задержкой записи под конкретную нагрузку (например, СУБД с высокой частотой транзакций), взять «просто побольше диска» на облачном тарифе не поможет — там другая природа хранилища.
• Выделенный сетевой порт без разделения полосы. На VPS сетевой канал почти всегда общий ресурс хоста, даже если в тарифе написано «10 Гбит/с» — по факту это делится с соседями. Если приложению нужна гарантированная полоса, а не «до», выделенный сервер с собственным физическим портом закрывает вопрос напрямую.
• Аппаратный RAID-контроллер с батарейным кэшем, прямой доступ к дисковым устройствам без прослойки виртуализации, конкретное поколение процессора с нужными инструкциями (например, AVX-512 для определённых вычислительных нагрузок).
• Проброс GPU в конфигурации, которой нет в списке облачных инстансов — либо конкретная модель видеокарты, либо число карт, либо режим passthrough без деления между виртуальными машинами.
• Тонкая настройка на уровне ядра: huge pages под конкретный объём памяти базы данных, привязка процессов к NUMA-узлам, кастомные модули ядра — всё это либо недоступно на виртуалке вовсе, либо доступно с оговорками, зависящими от гипервизора хостера.

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

Предсказуемость важнее пиковой мощности

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

Для многих задач эта вариативность не критична: если сайт иногда отвечает не за 80 мс, а за 150 мс, никто не заметит. Но есть классы нагрузок, где стабильность отклика важнее его среднего значения:

• торговые и биржевые системы, где задержка в лишние десятки миллисекунд буквально стоит денег;
• обработка в реальном времени — стриминг, VoIP, игровые серверы, где важен джиттер, а не только средняя задержка;
• системы с жёсткими SLA по времени ответа, где важен не средний перцентиль, а p99 или p999 — редкие, но регулярные выбросы недопустимы по контракту.

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

Признак-ловушка: приложение медленное не из-за нехватки ресурсов

А теперь — ситуация, которая внешне выглядит точь-в-точь как первые пять признаков, но лечится совершенно иначе. Сайт или API отвечает медленно, пользователи жалуются, первая реакция — «нужен сервер помощнее». Но если заглянуть в метрики в момент этой самой медленной обработки и увидеть, что CPU загружен на 15%, память наполовину свободна, а диск не пишет с потолка, — вывод должен быть не «значит, ресурсов пока хватает, странно», а «ресурсы не проблема, ищите дальше».

Классические архитектурные причины медленности, которые не имеют отношения к объёму железа:

• N+1 запросы к базе — вместо одного запроса за списком с джойном код делает один запрос за списком и по одному дополнительному запросу на каждый элемент. При 10 элементах это незаметно, при 500 — секунды задержки при копеечной нагрузке на CPU.
• Отсутствие индексов под реальные запросы — база честно перебирает таблицу целиком при каждом обращении, и рост объёма данных линейно замедляет каждый запрос независимо от мощности процессора.
• Отсутствие слоя кэширования там, где одни и те же данные пересчитываются или перезапрашиваются заново при каждом обращении, хотя могли бы отдаваться из Redis или локального кэша за микросекунды.
• Синхронные блокирующие операции в коде, который должен быть асинхронным: один медленный внешний вызов (API, письмо, файловая операция) блокирует обработчик целиком, и запросы выстраиваются в очередь, даже когда свободных ядер физически достаточно.

Здесь стоит явный практический совет: переход на самое мощное железо в такой ситуации не решает проблему, а откладывает её симптом. Больше ядер и памяти дают немного запаса прочности — очередь запросов рассасывается чуть быстрее, N+1 на маленьком объёме данных не так заметен, — но при дальнейшем росте нагрузки или объёма данных та же самая архитектурная проблема вернётся, просто на бóльших числах, а деньги за более мощный сервер уже потрачены. Восемь конкретных причин такой «тихой» медленности при формально свободных ресурсах и команды для их диагностики разобраны отдельно в статье «всё работает, но медленно»: восемь причин, которые не ищут.

Как проверить объективно, прежде чем платить за выделенный сервер

Прежде чем принимать решение о переходе, стоит потратить пару часов на объективную проверку, а не действовать по ощущению «наверное, надо помощнее». Порядок простой:

1. Соберите историю нагрузки за 1-2 недели, а не разовый снимок — CPU, память, диск, сеть, отдельно для пиковых и непиковых часов.
2. Проверьте steal time (vmstat, top) за тот же период — растущий и ненулевой st при низкой собственной загрузке сразу указывает на проблему хоста, а не приложения.
3. В момент жалобы на медленность посмотрите на метрики именно этого момента. Высокая загрузка CPU/памяти/диска в момент проблемы — сигнал в пользу ресурсов. Низкая загрузка при том же тормозе — сигнал в пользу архитектуры: смотрите долгие запросы к базе (slow query log), внешние вызовы, блокирующие операции.
4. Посчитайте деньги явно, если признак — экономический: сложите текущие расходы на все VPS проекта и сравните с ценой выделенного сервера сопоставимой мощности за тот же период, включая простой на переезд.
5. Сверьте список требований с тем, что вообще есть в тарифной сетке облака, если подозреваете признак про специфичное железо — иногда нужного варианта просто нет ни на каком тарифе, и это быстро закрывает вопрос.

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

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