Сетевые лимиты виртуалки: почему пакеты в секунду важнее заявленных гигабит

MAATRIX

Вы арендовали виртуалку с заявленным каналом 1 Гбит/с, но DNS-резолвер или игровой сервер на ней захлёбывается на трафике, который по мегабитам едва тянет на десятую долю канала. При этом соседний проект с файловым сервером на той же виртуалке спокойно выгружает сотни мегабит в секунду. Разгадка не в канале — она в лимите пакетов в секунду (PPS), о котором тарифный план обычно молчит.

Почему гигабиты в секунду — не главная метрика

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

Дело в том, что обработка одного пакета — это фиксированная по объёму работа для CPU независимо от размера самого пакета. Гипервизору (KVM/QEMU с virtio-net, Xen, Hyper-V) нужно на каждый пакет: принять прерывание или тик опроса очереди, скопировать или замапить буфер между хост-памятью и памятью гостя, прогнать пакет через виртуальный коммутатор (Open vSwitch, Linux bridge, SR-IOV фильтры), применить правила firewall/security group, обновить счётчики. Эта работа стоит примерно одинаково что для пакета в 64 байта, что для пакета в 1500 байт (стандартный MTU Ethernet).

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

Простой пример на пальцах. Если лимит виртуалки — условно 300 000 pps (цифра для иллюстрации механики, не ориентир по вашему тарифу — у каждого провайдера она своя и часто не публикуется), то:

• Трафик пакетами по 1400 байт: 300 000 × 1400 × 8 бит ≈ 3,3 Гбит/с — то есть канал 1 Гбит/с исчерпается раньше, чем упрётесь в PPS.
• Трафик пакетами по 64 байта (характерно для DNS-запросов, части VoIP-пакетов, SYN-флуда): 300 000 × 64 × 8 бит ≈ 150 Мбит/с — то есть вы упрётесь в PPS, имея в загрузке канала жалкие 15% от заявленного гигабита.

Формула здесь одна: pps × размер\_пакета\_в\_байтах × 8 = битрейт. Меняя средний размер пакета, вы двигаете точку, в которую упрётесь первой — в канал или в PPS.

Кто чаще всего упирается в PPS

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

• DNS-серверы и резолверы. Запрос и ответ — это, как правило, один-два пакета размером в десятки-сотни байт. Резолвер, который держит тысячи запросов в секунду, генерирует огромный PPS при скромном битрейте.
• Игровые серверы. Тикрейт 30–128 обновлений в секунду на игрока означает поток мелких UDP-пакетов с позициями и событиями. Сотня игроков на сервере — это уже заметная нагрузка по PPS при копеечном трафике в мегабитах.
• VoIP и видеоконференции. Кодеки голоса режут поток на пакеты по 20 мс, это десятки-сотни пакетов в секунду на один звонок, каждый пакет крошечный.
• Мелкие DDoS-атаки и сканирования. SYN-флуд, UDP-флуд с мелкими пакетами, ICMP-флуд — классический способ положить сервис, не выбирая канал, а просто исчерпав его способность обрабатывать пакеты. Иногда 150–200 Мбит/с такого трафика кладут сервер с заявленным каналом 1 Гбит/с наглухо, потому что упор идёт не в канал, а в PPS и в CPU обработки.
• Микросервисная сеть с частыми короткими запросами — health-check'и, gRPC-стримы с маленькими сообщениями, брокеры очередей с высокой частотой мелких сообщений.

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

Почему провайдеры лимитируют PPS отдельно от канала

Ограничение по PPS — это не каприз, а защита общего ресурса: CPU хост-машины, который делят между собой десятки виртуалок. Если один арендатор гонит трафик мелкими пакетами и нагружает виртуальную сетевую карту и гипервизор на полную катушку, он забирает процессорное время у соседей по тому же физическому серверу — тот самый CPU steal, знакомый по другим темам overcommit.

Поэтому у большинства крупных облаков лимит PPS привязан к размеру инстанса (числу vCPU) отдельно от лимита по мегабитам — это подтверждённая документацией практика у AWS, Google Cloud и Azure, где сетевая производительность инстанса описывается не только полосой, но и предельным числом пакетов в секунду. Точные цифры нужно смотреть в актуальной документации конкретного провайдера на момент аренды — они меняются между поколениями инстансов и типами виртуальных сетевых карт.

Хуже то, что многие менее крупные хостеры и VPS-провайдеры лимит PPS в тарифе вообще не публикуют, ограничиваясь фразой «канал 1 Гбит/с» или даже «безлимитный трафик». Формально это не обман — лимит PPS чаще существует не как жёсткая настройка биллинга, а как физический потолок: сколько пакетов в секунду успевает обработать конкретная конфигурация гипервизора, виртуальной сетевой карты и выделенных вашей VM vCPU-ядер, прежде чем очередь на приём начинает переполняться и пакеты теряются. Для вас как для арендатора результат один и тот же — трафик мелкими пакетами упирается в потолок раньше, чем канал в мегабитах.

Как понять, что вы упёрлись именно в PPS, а не в канал

Главный диагностический признак — расхождение между низкой загрузкой канала в мегабитах и высокой загрузкой CPU на обработку сети. Порядок проверки:

1. Смотрите загрузку канала. ip -s link show eth0 или sar -n DEV 1 покажут текущий rx/tx в пакетах и байтах в секунду за интервал. Если Мбит/с далеки от заявленного лимита тарифа, а проблемы с сетью (потери, задержки, таймауты) уже есть — это первый звоночек.

sar -n DEV 1 5

Смотрите на колонки rxpck/s и txpck/s (пакеты в секунду) рядом с rxkB/s/txkB/s (мегабайты в секунду). Если pck/s растёт, а kB/s почти не меняется — у вас мелкие пакеты, и именно pps будет узким местом.

1. Смотрите загрузку CPU на софтверные прерывания. mpstat -P ALL 1 или просто top/htop с разбивкой по ядрам — ищите высокий %si (softirq) на одном или нескольких ядрах. Если одно ядро упирается в 100% на softirq, а остальные простаивают — это типичная картина, когда весь входящий трафик обрабатывается одной очередью на одном CPU.

mpstat -P ALL 1 5

1. Проверьте счётчики самой сетевой карты на предмет отброшенных пакетов. ethtool -S eth0 | grep -i drop (для virtio-net имена счётчиков будут вида rx_queue_0_drops или похожие) и cat /proc/net/dev — колонки drop и errs для интерфейса. Растущий счётчик drop на фоне низкого битрейта — прямое подтверждение, что теряются именно пакеты, а не байты канала.

cat /proc/net/dev
ethtool -S eth0 | grep -iE "drop|discard|error"

1. Проверьте, сколько очередей у виртуальной сетевой карты и как они разложены по ядрам. ethtool -l eth0 покажет число доступных и используемых combined-очередей (Combined). cat /proc/interrupts | grep eth0 покажет, какие ядра обслуживают прерывания сетевой карты — если все запросы идут на одно ядро (IRQ0), это симптом, что multi-queue либо не настроен, либо у виртуалки всего одно vCPU.

ethtool -l eth0
cat /proc/interrupts | grep eth0

Совокупность признаков «низкий Мбит/с + высокий %si на одном ядре + растущие drop-счётчики» — это почти всегда упор в PPS, а не в канал. Если вместо этого высокая утилизация Мбит/с при низком %si — узкое место классическое, полоса канала, и тут работает стандартная логика выбора между тарифами 1G и 10G.

Как снизить нагрузку по PPS на своей стороне

Полностью раздвинуть лимит PPS, который держит провайдер, вы не можете — это ограничение хоста. Но можно эффективнее использовать то, что уже выделено, распределив обработку пакетов по нескольким vCPU вместо одного.

Multi-queue и RSS. Современные виртуальные сетевые карты (virtio-net с multiqueue, SR-IOV с VF) умеют распределять входящие пакеты по нескольким очередям приёма, каждая из которых обрабатывается на своём CPU — это называется RSS (Receive Side Scaling), тот же механизм, что используется на физическом железе. Если у вашей виртуалки несколько vCPU, но сеть всё равно обрабатывается одним ядром — вероятно, multiqueue просто не включён.

Проверить и включить число очередей на стороне гостя:

ethtool -l eth0          # показывает Pre-set maximums и Current hardware settings
ethtool -L eth0 combined 4   # включить 4 очереди, если карта их поддерживает

Если ethtool -l показывает, что Pre-set maximums равен 1, значит виртуальная сетевая карта сконфигурирована гипервизором без поддержки нескольких очередей — это настраивается на стороне хоста (для KVM/QEMU — параметр queues=N в конфигурации virtio-net, привязанный к числу vCPU), и тут уже нужно смотреть, что позволяет тариф провайдера.

IRQ affinity и распределение прерываний. Если очередей несколько, но все прерывания всё равно летят на одно ядро, проверьте irqbalance (он должен быть запущен и активен) либо руками разложите affinity прерываний по /proc/irq/<N>/smp_affinity. Это тема, тесно связанная с тем, как ядро вообще распределяет прерывания сетевой карты между CPU — общий механизм разобран в статье про прерывания и почему сетевая карта отбирает у вас целое ядро.

Число vCPU имеет значение само по себе. Multi-queue распределяет нагрузку, но если у виртуалки всего 1–2 vCPU, распределять особо некуда — весь бюджет CPU на обработку сети остаётся крошечным. Для нагрузок с заведомо мелкопакетным профилем (DNS, VoIP-шлюз, игровой сервер на много игроков) число vCPU иногда важнее объёма RAM или размера диска — вопреки интуиции «сеть — это отдельная штука, не CPU».

Укрупнение пакетов, где это возможно. Не всегда применимо (протокол диктует размер), но там, где можно — батчинг сообщений в приложении (объединение нескольких мелких сообщений в один пакет перед отправкой) снижает PPS ценой небольшой задержки. Для протоколов реального времени (голос, игры) это компромисс с задержкой, который не всегда приемлем, но для очередей сообщений, метрик, логов — часто безболезненный способ снять нагрузку с PPS.

Как выбирать тариф с оглядкой на профиль нагрузки

Если ваш трафик — это преимущественно мелкие пакеты, ориентироваться только на заявленную полосу в мегабитах при выборе VPS — ошибка. Что стоит делать вместо этого:

• Оцените реальный профиль нагрузки заранее. Для DNS — ожидаемое число запросов в секунду. Для игрового сервера — тикрейт × число игроков × число полей в апдейте (грубая оценка, но лучше, чем ничего). Для VoIP-шлюза — число одновременных звонков × пакетов в секунду на звонок у используемого кодека.
• Спрашивайте у провайдера явно про лимит PPS, а не только про канал — это не всегда написано в публичном тарифе, но добросовестный провайдер отвечает на прямой вопрос в поддержке или в описании тарифа для профильных нагрузок.
• Смотрите не только на канал, но и на число vCPU и тип виртуализации. KVM с современным virtio-net и поддержкой multiqueue в среднем ведёт себя ощутимо лучше по PPS на пакет, чем старые схемы полной эмуляции сетевой карты — уточняйте у провайдера, какой драйвер сетевой карты используется в гостевой ОС по умолчанию.
• Не путайте задачу с задачей выбора канала. Вопрос «1G или 10G» — это отдельная история, разобранная в статье про сетевой канал 1G против 10G: она про объём передаваемых данных, а не про число пакетов. Обе метрики нужно проверять отдельно.
• Для мелкопакетных нагрузок закладывайте запас по vCPU, а не только по каналу — как показано выше, именно CPU на обработку прерываний чаще становится потолком раньше канала.
• Тестируйте на реальном профиле трафика перед продакшеном, а не полагайтесь на iperf с крупными пакетами по умолчанию — iperf3 умеет генерировать UDP-трафик заданного размера пакета флагом -l, что ближе к реальному сценарию:

iperf3 -c server_ip -u -b 200M -l 64 -t 30

Такой прогон с мелкими UDP-пакетами (64 байта) при относительно скромном битрейте 200 Мбит/с быстрее покажет реальный потолок PPS, чем стандартный тест с пакетами по 1400+ байт, который в первую очередь выберет канал.

Как это соотносится с другими сетевыми узкими местами

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

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