Сеть в VM вешается под нагрузкой

Что я пробовал

Также попробовал пробросить сетевую карту силами sriov.

Проверить iperf не с кем (до гипервизора по какой-то причине трафик не ходит, допускаю что криво настроил сеть)
Но приложение всё так-же виснет со временем и также наблюдаю просадки и потери пакетов ping до VM, что трактую как сетевую проблему.

В порядке убывания правильности (с моей точки зрения):

1. Переставить сеть в шину к CPU1;
2. Сделать PCI passthrough карточки внутрь VM;
3. RTFM в сторону https://docs.kernel.org/networking/scaling.html и https://docs.kernel.org/core-api/irq/irq-affinity.html и https://blog.cloudflare.com/how-to-achieve-low-latency/ и т.п. прибивая RX очереди и TX очереди к своему CPU2.

Переставить сеть в шину к CPU1;

нет такой возможности

Сделать PCI passthrough карточки внутрь VM;

опробовано комментарием выше, косвенно проблема осталась, может позже придумаю как более точно проверить

RTFM в сторону

Пойду читать…

Помониторьте /proc/interrupts в момент проблем — какие прерывания лидируют? Проще всего каким-нибудь prometheus или netdata. На худой конец watch -n 5 -d cat /proc/interrupts, если экрана хватит на многоядерной системе. Исключить ядро/драйверы.

Смущают ровно 5 секунд до затыка — как будто планировщик при росте нагрузки влезает.

Что за процессоры? Кто управляет частотой/питанием — сервер или ядро?

watch -n 5 -d cat /proc/interrupts, если экрана хватит на многоядерной системе.

ens1f0-fp-X, где X от 0-15. Соответствует имени интерфейса 10Gb/s сетевой карты на которую приходится трафик.
Что кстати странно, в общении участвуют только VM и гипервизор, зачем дёргать физическую сетевую карту?

Что за процессоры? Кто управляет частотой/питанием — сервер или ядро?

CPU E5-2683 v4 @ 2.10GHz, силами tuned включен профиль virtual-host, что подразумевает под собой cpu governor=performance

Сделать PCI passthrough карточки внутрь VM; опробовано комментарием выше, косвенно проблема осталась, может позже придумаю как более точно проверить

Проверил точно. Пробросил другой порт, который подключен к такой-же карточке соседнего гипервизора.

iperf в 3 потока успешно утилизировал весь канал в обе стороны без каких либо проблем.

ХМ, я совсем неправильно описал проблему.

В VM наблюдаю картину root@avreg889:~# iperf3 -c 192.168.236.12 и всегда 1Gb/s в обратную сторону

Я неправильно запускал тест. У меня на гипервизоре 236.12 это адрес моста с 1Gb/s интерфейсом и br1 мост без IP с 10Gb карточкой и VM.
Поэтому такой iperf тест ходил петлёй через коммутатор с гигабитным портом с одной из сторон.

Почему я после поднятия интерфейса в VM в начале теста видел ~20Gb/s для меня загадка.

Попробуй увеличь размер кадра (MTU) на сетевой и со стороны оборудования куда она подключена.

ХМ, я совсем неправильно описал проблему.

Попробую ещё раз.

Есть ПО avreg, с кучей камер. avreg с каждой камеры забирает 2 потока: основной для записи без декодирования и вторичный ~720p для просмотра с декодированием.
Где-то для половины камер пришлось явно забирать rtsp поток по tcp.

Проблема: стоит запустить avreg он в течении нескольких минут начинает вешаться с кучей ошибок переподключений к камерам. Это зависание всегда сопровождается кратными «скачками» LA до значений в 2-8X от «обычной нагрузки сервиса»

В качестве сети проброшенная по SRIOV сетевая карта.

Как я вижу проблему:

• В процессе работы LA подскакивает до каких-то нереально больших значений, потом может зависнуть в этом состоянии или постепенно опускаться до «нормальных» значений. И так периодически.
  • При этом ping VM показывает «просадки» времени ответа до 500ms и/или потери
  • Также ip -s -s link show показывает сильный рост rx_errors, ethtool -S это показывает как rx_discards
  • avreg всегда рядом с проблемой начинает спамить сообщениями об отвале камер

Я вроде понимаю, что у меня CPU не справляется с забирать пакетики от сетевой карты, но работающего решения не нашёл

Что я уже успел попробовать:

• net.core.netdev_budget=9600 и net.core.netdev_budget_usecs=48000 с виду заставляют проблему возникать «реже», но не более
  • по крайней мере скорость и частота прироста rx_errors резко падает, но «просадки ping» остаются и почти всегда коррелируют с ростом rx_errors и ошибками avreg
  • выставление значений netdev_budget выше 1200 с виду не имеет особого эффекта
• ethtool -g показывает, что буферы на стороне сетевой карты уже выставлены на максимум, увеличивать нечего
• ethtool -k большая часть оптимизаций включены, для драйвера bnx2x явных тем вида «отключите то-то» не вижу, оставляю как есть
• Установка и включение сервиса irqbalance с виду не меняет ничего или явно делает хуже
• Любые варианты запуска iperf не вызывают проблему
• Сетевая карта не позволяет менять MTU или я не понял как это делать

Попробуй в sysctl.conf добавь
vm.overcommit_memory = 1
vm.overcommit_ratio = 100
vm.vfs_cache_pressure = 1000
net.core.default_qdisc = fq_codel
net.ipv4.tcp_congestion_control = cubic
net.ipv4.tcp_mtu_probing = 1
vm.laptop_mode = 0

В iptables

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o eth1 -j TCPMSS --clamp-mss-to-pmtu

Где eth1 твои сетевые карты.
И ethtool -r сетевая карта

Когда sysctl.conf правишь перезагружаться не забывай

Странные параметры, но ладно. Применил

sysctl vm.overcommit_memory=1
sysctl vm.overcommit_ratio=100
sysctl vm.vfs_cache_pressure=1000
sysctl net.ipv4.tcp_mtu_probing=1
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -o ens11 -j TCPMSS --clamp-mss-to-pmtu

Остальные параметры уже в нужных значениях. Разницы не увидел, откатил.

Когда sysctl.conf правишь перезагружаться не забывай

Допускаю для теста поправить параметры без правки conf файлов не перезагружаясь, проверил оба варианта на всякий

Скорее всего debian собран без серверных инструкций CPU.
На gentoo я наблюдал двукратный буст при сборке всей системы под нативную архитектуру процессора.
Вот скорость просто помноженная на 2.
Там всё быстрее и особенно сеть.
cpu governor=performance это не совсем правильный метод.
Нужно выставлять минимальную частоту примерно 40 или 50% от максимальной в турбобусте.
Например --governor schedutil -d 2GHz -u 4GHz
Некоторые чипсеты могут выставлять частоту до мегагерца в точности.
У некоторых фиксированные уровни, это тоже учитывайте.

А ты не пробовал сделать виртуальную сетевую карту в qemu? virtio+vhost

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

Когда sysctl.conf правишь перезагружаться не забывай

зачем? sysctl позволяет модифицировать параметры в процессе работы системы.

Я начал с virtio+vhost и также наблюдал проблему + ещё и на гипервизоре в виде tx_errors на vnet интерфейсе.

Поэтому пробросил сетевую в VM чтобы исключить сеть гипервизора.

Скорее всего debian собран без серверных инструкций CPU.

Вы про x86-64-vX?

Если да, то и на гипервизоре и в VM

# ld.so --help
...
Subdirectories of glibc-hwcaps directories, in priority order:
  x86-64-v4
  x86-64-v3 (supported, searched)
  x86-64-v2 (supported, searched)
...

Не вижу тут явных проблем. Поменять ОС на гипервизоре всёравно не получится

Ну тогда хз, может и невозможно сделать то, что ты хочешь.

Работа с проброшенным железом все равно идет через хост систему, точнее, через модуль ядра который обрабатывает VMX или SVM прерывания, т.е. переключение в контекст ядра хост системы все равно происходит, а сеть гипервизора вся в ядре, поэтому там нет дополнительного переключения из пространства пользователя… ну чисто теоретически…

Откатился на вариант с vnet (bridge на гипервизоре и к нему подключена VM) и кажется сделал достаточно лучше за счёт:

• Включил multiqueue для сети. В libvirt это добавить <driver name="vhost" queues="16">
  • я ранее это уже пробовал но оно не дало эффекта
• Увеличил размер очереди для vnet интерфейса # ip l set vnet7 txqlen 16000
  • пока руками, потом как-то автоматизирую
• Внутри VM выставил net.core.netdev_budget=9600 net.core.netdev_budget_usecs=48000

После этого не вижу чтобы явно пакеты терялись.

Сильно долго копаю, точно знаю что только первого пункта мало, возможно что-то из других пунктов тоже лишнее, но откатывать уже не буду.

Есть ещё какие-то странности в VM, но явно не могу их с сетью увязать, пока понаблюдаю…