Оптимизация пропускной способности VPP через изоляцию ядер
Х@habr_com2 дн
Разбор оптимизации Data Plane в Overlay-сети: как изоляция ядер (isolcpus) повысила пропускную способность VPP на 42%.
Четыре worker-потока и один параметр ядра: +42% пропускной способности
Команда Network DPL в MWS Cloud Platform опубликовала подробный разбор того, как устроен Data Plane в их Overlay-сети. Внутри — связка QEMU, VPP и SRv6, выбранная намеренно: сложные архитектуры хорошо выглядят на слайдах, но обрастают непредсказуемым поведением под нагрузкой и требуют армии инженеров, чтобы просто не развалиться.
Бенчмарки проводились на реальной боевой ноде с Intel Xeon Gold 6448H. Четыре worker-потока VPP без изоляции ядер дали 62 Гбит/с. Те же четыре worker-а с isolcpus выдали уже 88 Гбит/с, и дисперсия результатов упала в разы. Один параметр загрузки ядра, никакого нового железа.
Разберёмся, почему именно столько и за счёт чего VPP на одном worker-потоке спокойно кормит три-четыре виртуальные машины суммарным трафиком под 40 гигабит.
Контекстдемо
Сюда AI будет дописывать короткий фон к сложным постам: что за история, кто участники, ключевые даты и почему это важно — чтобы понять пост без гугления.
Блок появляется только там, где без контекста не разобраться. Сейчас это демо-превью — реальный контекст начнёт генерироваться на бэкенде.
Кратко (AI)
Команда MWS Cloud Platform поделилась результатами оптимизации сетевого стека VPP. Использование параметра isolcpus для worker-потоков позволило увеличить пропускную способность с 62 до 88 Гбит/с на реальном железе.
Обсуждение
3Полезный разбор. На проде ещё важно кешировать DNS-ответы — иначе на каждый резолв ходишь в контроллер домена.
Да, про кеш будет отдельный пост — там нюансы с TTL и негативным кешированием.
А как это соотносится с mDNS в мелких сетях? Или это уже другая история?