Коротко — то, что вы видите, может быть и «халтурным» хостингом, и проблемой в канале/накоммутированном оборудовании, и просто особенностью политики shaping/oversubscription. Steal 2–5% сам по себе не критичен (означает, что гипервизор иногда забирает CPU на доли процента), но не исключает «шумы» от соседей или сетевых ограничений, которые проявляются как резкие просадки пропускной способности.
Дальше — как диагностировать и что смотреть. Привожу набор тестов и команды + что по ним можно понять.
1) Правильные iperf3-прогоны
- Запустите тесты в обе стороны (клиент->сервер и сервер->клиент):
- iperf3 -c <peer> -t 300 -P 10 -i 10 (несколько потоков, длительное время)
- iperf3 -c <peer> -t 300 -P 10 -R (реверсный тест)
- UDP для потерь/джеиттера:
- iperf3 -c <peer> -u -b 0 -t 60 -i 10 (или задать ожидаемую полосу)
Интерпретация: если TCP с несколькими потоками даёт стабильную суммарную скорость → проблема с одним TCP-потоком (window, latency). Если и многопоточный показывает скачки — сеть/шапинг/перегрузка.
2) Проверка packet loss / latency / routing
- mtr -rzbc100 <peer> — покажет потерю пакетов и где она возникает (хост → шлюз/провайдер).
- traceroute/tracepath — проверить асимметрию маршрута.
Интерпретация: потеря начинающаяся на первом/втором хопе — локально/у хостера; дальше — в провайдере.
3) Сетевые счётчики на VM и на хосте (если есть доступ)
- ip -s link show dev eth0 или cat /proc/net/dev — смотреть RX/TX dropped, errors.
- ethtool -S eth0 — статистика адаптера (CRC, drops, fifo, tx_errors).
- dmesg | egrep -i 'eth|net|tx|rx|error' — ошибки драйвера.
Если видите drops на интерфейсе/ошибки — возможны аппаратные/драйверные проблемы или проблема на физическом порту.
4) Проверка qdisc / shaping на VM
- tc -s qdisc show dev eth0 — видим, не стоит ли внутренняя полоса/политика.
Если есть тbf/htb — возможно токен-бакет с burst: сначала высокая скорость, потом падение до гарантированной.
5) Проверка softirq / irq / CPU
- cat /proc/interrupts и watch -n1 cat /proc/interrupts — смещение прерываний по CPU.
- mpstat -P ALL 1 — softirq/cpu загрузка.
- cat /proc/net/softnet_stat — если там растёт backlog/дропы — проблемы с обработкой пакетов.
Steal 2–5% — небольшая фоновая потеря CPU, но если скачки пропускной сопровождаются всплесками steal — это признак пересечения ресурсов на хосте.
6) Проверка retransmits/RTT на TCP
- ss -i или netstat -s — смотреть retransmits.
- tcpdump -w capture.pcap host <peer> — анализить tcp retransmits, dup acks.
Много retransmits → потеря/дроп/плохая латентность.
7) Привязка/оценка NIC: offloads, MTU, RPS/XPS
- ethtool -k eth0 — offload включены ли (gso/sg/tx offload). Иногда выключение/включение меняет картину.
- ip link set dev eth0 mtu 9000 (только если поддерживается) — тест jumbo frames.
- cat /proc/irq/*/smp_affinity и настройка RPS/XPS — если пакетная обработка идёт на одном CPU, возможны узкие места.
8) Локальные системные метрики в момент падения
Запускайте:
- vmstat 1
- iostat -x 1
- top/htop (следить за steal)
- sar -n DEV 1 60
Синхронизируйте время логов (ntp/chrony) чтобы совпадения с падениями были точными.
9) Что укажет на «шумного соседа» vs сетевой канал/провайдер
- Шумный сосед: одновременно со скачками вашей скорости растёт steal/CPU usage/softirq, появляются spikes в interrupts, и/или видно на hypervisor (если провайдер дал данные) сильная активность других VM.
- Провайдер/маршрут/политика shaping: потеря/ограничение видны на первом/втором хопе в mtr, или поведение соответствует «burst→падение до rate» — типичное для token-bucket/policing.
- Физическое насыщение порта: если на физическом порту много traffic (у хостера) — видны drops на физическом интерфейсе, возможно только провайдер увидит.
10) Что делать дальше / как собрать доказательства для хостера
- Записать iperf3 лог (несколько длительных прогонов, обе стороны), mtr/trace, tcpdump capture, выводы ethtool/tc/ip -s link, снимки top/vmstat с отметкой времени.
- Передать провайдеру: время инцидента + логи. Попросить проверить соседние VMs и мониторинг порта коммутатора, stats с hypervisor.
Короткие практические команды (одноразово)
- iperf3 -c <peer> -t 300 -P 10 -i 10 > iperf.log
- iperf3 -c <peer> -u -b 0 -t 60 -i 10 > iperf_udp.log
- mtr -rzbc100 <peer> > mtr.log
- tcpdump -i eth0 host <peer> -w capture.pcap
- ethtool -S eth0 > ethtool.log
- tc -s qdisc show dev eth0 > tc.log
- cat /proc/net/dev > dev.log
- vmstat 1 300 > vmstat.log
Вывод / резюме
- Steal 2–5% сам по себе не доказывает «лохматый хостинг», но резкие падения трафика чаще всего вызваны либо сетевым shaping/полисингом (часто на уровне провайдера/виртуального свича), либо перегрузкой физического порта/коммутатора из‑за oversubscription, либо редкими spikes у соседних VM. CPU-steal, softirq/interrupt spikes и drops на интерфейсе — самые полезные индикаторы «шумного соседа».
- Соберите логи (iperf, mtr, tcpdump, ethtool, tc, vmstat) и передайте провайдеру — они обычно могут быстро проверить состояние физического порта и виртуального свича.
Если хотите, могу подготовить компактный скрипт, который соберёт все нужные команды и логирование за минут — скажите, где запускать (VM или удалённый peer) и я сгенерирую.