Шумный сосед на гипервизоре: как обнаружить и что делать

MAATRIX

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

Что такое шумный сосед и почему это вообще возможно

Когда вы арендуете VPS, вы получаете не отдельный физический сервер, а виртуальную машину, которая делит одно физическое железо с несколькими (иногда десятками) другими виртуалками. Гипервизор — KVM, Xen, VMware, механизм в целом похожий — распределяет между ними процессорное время, дисковый ввод-вывод и пропускную способность сети. В нормальном режиме большинство VPS большую часть времени простаивают, и общих ресурсов хватает всем.

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

Оговорка сразу: сам факт общих ресурсов — не поломка и не обман. Умеренный оверселлинг (продажа ресурсов с расчётом, что не все арендаторы упрутся в потолок одновременно) — стандартная и экономически оправданная практика хостинга, подробно разобрана в статье оверселлинг в цифрах: как понять, что вам продали воздух. Шумный сосед — конкретный, диагностируемый случай, когда оверселлинг на практике бьёт именно по вам и именно сейчас, а не абстрактный факт «ресурсы общие».

Дальше — три типа ресурса, для каждого своя диагностика, потому что симптомы и инструменты проверки принципиально разные.

CPU: steal time как прямой индикатор

Для процессора у Linux есть отдельная метрика, которая напрямую отвечает на вопрос «отбирает ли у меня кто-то ядро» — steal time, колонка st в выводе vmstat и top. Это не догадка и не косвенный признак: гостевая ОС получает эту информацию через паравиртуальный интерфейс гипервизора и умеет отличать «я сам простаивал» от «я хотел работать, но мне не дали физическое ядро».

Смотрится одной командой с обновлением раз в секунду:

vmstat 1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 2  0      0 512340  81200 934120    0    0     2    18  120  340 12  4 82  0  2
 1  0      0 511980  81200 934300    0    0     0    12  115  330 10  3 84  0  3

Последняя колонка — st. То же самое видно в top в строке %Cpu(s), там st идёт последним параметром. Если нужна разбивка по ядрам, а не усреднённая цифра, — mpstat -P ALL 1: гипервизор не обязан отбирать время равномерно у всех виртуальных ядер, и на многоядерной VM проблема иногда видна только на одном-двух ядрах из нескольких.

Ключевое правило чтения — смотреть не на один снимок, а на динамику. Разовый всплеск st на несколько секунд — нормальная конкуренция за ресурс. А вот стабильно ненулевой st, который держится часами и нарастает со временем, — уже характеристика конкретного физического хоста. Развёрнуто про механику метрики и разницу между steal time и обычной загрузкой CPU (us/sy) — в статье steal time: как понять, что сосед по железу ест ваш процессор.

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

#!/bin/bash
# steal_log.sh
while true; do
  ST=$(vmstat 1 2 | tail -1 | awk '{print $17}')
  echo "$(date '+%F %H:%M') st=${ST}" >> ~/steal_log.txt
  sleep 300
done

Такой лог за несколько дней — это уже не ощущение «сервер тормозит», а конкретные цифры с метками времени, с которыми можно идти в поддержку.

Диск: скачки await, не объяснимые своей нагрузкой

Для дискового ввода-вывода прямой аналог steal time — задержка операций, которую показывает iostat из пакета sysstat:

iostat -x 1

Интересующая колонка — await (иногда отдельно r_await/w_await на новых версиях) — среднее время в миллисекундах, которое операция ввода-вывода ждёт выполнения, включая время в очереди. Полезно смотреть рядом и %util — загрузку устройства:

Device            r/s     w/s   rkB/s   wkB/s  await  r_await  w_await  %util
vda              12.00   45.00  480.00 1820.00   3.20     1.10     4.30   18.50

Логика та же, что по CPU: разовый скачок await — скорее всего, ваш же бэкап, обновление пакетов или запись большого файла, и он совпадает по времени с вашей активностью. А вот резкий, непредсказуемый рост await, когда приложение само почти не пишет и не читает с диска (проверяется сопоставлением с логами приложения), — признак, что физический накопитель (или сетевое SDS-хранилище, если тариф использует его вместо локального NVMe) в этот момент интенсивно нагружает кто-то другой на том же хосте.

Отличать разовые пики от системной проблемы удобно, повторяя один и тот же тест в разное время суток при помощи fio — это позволяет увидеть, не проседает ли IOPS/latency предсказуемо в одни и те же часы независимо от вашей собственной нагрузки:

apt install fio -y
fio --name=randread_test --directory=/tmp --rw=randread \
    --bs=4k --size=1G --numjobs=4 --iodepth=32 \
    --runtime=60 --time_based --group_reporting

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

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

Сеть: самый сложный случай для диагностики изнутри VM

Сетевую деградацию из-за шумного соседа диагностировать изнутри собственной VM сложнее всего — здесь нет метрики уровня steal time, которая прямо указывала бы «виновата чужая нагрузка на общем аплинке». Видны только косвенные симптомы: пинг скачет без причины, скачивание файла зависает на середине и продолжается, SSH-сессия секунду «думает» перед каждой командой, iperf3-тест до внешнего сервера показывает то нормальную, то заметно проседающую пропускную способность — при стабильной собственной нагрузке.

Первый шаг — исключить себя. Проверить собственную нагрузку на интерфейс:

iftop -i eth0
nload eth0
vnstat -l

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

ping -i 1 1.1.1.1 | while read line; do echo "$(date '+%F %H:%M:%S') $line"; done >> ~/ping_log.txt

и/или mtr для трассировки с накоплением статистики по каждому хопу:

mtr --report --report-cycles 100 1.1.1.1

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

Честно предупредим: даже собрав такую статистику, доказать на 100%, что виноват именно сосед (а не промежуточный узел сети провайдера или ваш собственный интернет-канал), не всегда возможно. Задача здесь не «доказать вину», а собрать достаточно данных, чтобы было о чём предметно говорить с поддержкой.

Как отличить реального шумного соседа от собственной неоптимизированной нагрузки

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

Признаки, что дело скорее в вас:

• Высокие us/sy в top (реальная загрузка вашими процессами), при этом st низкий или нулевой.
• Проблема стабильно совпадает по времени с пиками именно вашей нагрузки (наплыв посетителей, крон-задача, миграция базы), а не возникает в моменты, когда вы сами простаиваете.
• Диск нагружен собственным приложением — логи, временные файлы, необновлённые индексы в базе, отсутствие кеширования на уровне приложения.
• Проблема исчезает после оптимизации запроса, добавления индекса, ограничения параллелизма в приложении — то есть решается на вашей стороне, без смены хостинга.

Признаки, что дело скорее в соседе:

• st стабильно ненулевой и растёт именно в те часы, когда собственная нагрузка (по us/sy и логам приложения) низкая.
• await в iostat скачет резко и непредсказуемо, не коррелируя с вашими операциями записи/чтения.
• Сетевая деградация повторяется в одно и то же время суток вне зависимости от того, что делаете вы сами.
• Проблема не устраняется оптимизацией собственного кода — метрики приложения в порядке, а внешние (или гостевые системные) метрики всё равно показывают деградацию.

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

Что делать, если шумный сосед подтверждён

Когда данные собраны и картина устойчиво повторяется не в вашу пользу, варианты по возрастанию радикальности такие.

1. Обратиться в поддержку провайдера с конкретными данными. Не «у меня тормозит», а лог steal time за несколько дней с метками времени, графики iostat -x в моменты просадок, результаты повторяющегося пинга или fio-теста в разное время суток. Это меняет разговор принципиально: вместо субъективной жалобы у поддержки на руках конкретный технический артефакт, по которому можно что-то сделать — например, перенести вашу VM на менее загруженный физический узел без смены тарифа. Это обычно самый дешёвый и часто самый эффективный шаг, стоит пробовать его первым.

2. Перейти на тариф с гарантированными ресурсами. У многих провайдеров есть разделение на «обычные» VPS с максимальным оверселлингом (дешевле) и тарифы с резервированием — гарантированные vCPU (иногда через CPU pinning), гарантированный минимум IOPS, отдельная полоса пропускания сети. Это стоит дороже, но если проблема хроническая, а не разовая, — переплата обычно окупается предсказуемостью.

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

Честная оговорка на каждом из этих шагов: умеренный оверселлинг — нормальная, экономически обоснованная практика, а не признак недобросовестности провайдера. Она и позволяет VPS стоить разумных денег: продавай все ресурсы строго 1:1 с железом — тарифы были бы в разы дороже. Не каждое замедление означает «виноват провайдер»: иногда это собственный неоптимизированный код, иногда разовая случайность, а иногда — действительно перегруженный хост. Разница не в ощущениях, а в цифрах: steal time, await, повторяемые замеры сети во времени.

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