John_obn

@nixxЭти тайминги я сделал такими же, какие были применены для Intel XL710: Coalesce parameters for ens6: Adaptive RX: off TX: off stats-block-usecs: 0 sample-interval: 0 pkt-rate-low: 0 pkt-rate-high: 0 rx-usecs: 50 rx-frames: 128 rx-usecs-irq: 0 rx-frames-irq: 0 tx-usecs: 50 tx-frames: 128 tx-usecs-irq: 0 tx-frames-irq: 0 rx-usecs-low: 0 rx-frames-low: 0 tx-usecs-low: 0 tx-frames-low: 0 rx-usecs-high: 0 rx-frames-high: 0 tx-usecs-high: 0 tx-frames-high: 0

@AzamatВ этом плане вы правы. Довод к тому, чтобы разобраться с загрузкой после замены на Мелланокс. Второй сервер менее нагружен, поэтому запас есть. Пока есть.

@AzamatКто сказал, что сервер один? 🙂

@Стич График idle ядер приложил. Пик приходится на 37,6 гигабит трафика в каждую сторону, 4,78Мппс, 1,46М трансляций. Очереди сетевой прибиты к своему процессору. Да, их стоит 2, но занят только один процессор, что видно из графика. HT включен. NAT родной, настраивал через nft. Тюнинг sysctl и в /etc/default/grub (mitigations=off): GRUB_CMDLINE_LINUX_DEFAULT="maybe-ubiquity mitigations=off Заметил, что после замены XL710 на Mellanox idle уменьшился в среднем на 5% (то есть загрузка возросла). Пока не критично, поэтому в причинах не разбирался.

По трафику мы добрались до 38,5G в пике, поэтому я решил заранее апгрейдиться. E5-2690 v4 Только ipt_netflow + NAT. @taf_321 - спасибо

Плохого ничего не скажу. Сам недавно заменил 40G Intel XL710 на 100G Mellanox Connect-x 5. Проблем не имел. Машина в роли on-stick, 1 влан смотрит в сторону внутренней сети, 1 влан во внешний мир (NATит трафик). С ходу не нагуглил, где эта проблема описана. Можете поделиться?

Вы из РФ? nix.ru, яндекс маркет находят без проблем X520 В качестве аналога X710. По 40G тоже проблем не видно - на чипе XL710 ищите там же.

@nixx Мониторю, Ubuntu 20 на ядре 5.4, график без пилы, ровные горочки с максимумом в 1.46М. Посмотрите, может у вас в sysctl таймауты поменялись в net.netfilter.nf_conntrack_ после обновления. Что сподвигло вас обновиться?

Нет

Индивидуально. У меня, к примеру, NAT на Ubuntu 20 (ядро 5.4) - показывает отличный результат; Debian 11 (ядро 5.10) показывает отличный результат на BRAS (iptables+ipt_ratelimit+ipt_netflow)

Если новых задач не планируется от машины, я бы оставил ubuntu 18 и не дергался.

sysctl значения такие же все остались?

Добрый день. Какая сетевая стоит? Если интел, то пробуйте оставить драйвер, который установлен в Ubuntu (не ставьте с sourceforge) Что у вас прописано в /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Ищите место, где они теряются. Смотрите дамп трафика на выходе с bgp и shaper в сторону NAT. Смотрите пакетики на входе в NAT. На промежуточных коммутаторах или маршрутизаторах (если таковые имеются). Счетчики ошибок/дропов на портах, и сетевых картах в эти моменты.

Решил свою проблему, описанную выше. Для начала вынес роль бордера на mx204 в надежде, что, оставив только роль NAT на сервере , чтобы не пришлось бегать по таблице маршрутизации, проблема уйдет. Но нет, проблема осталась. Машину под NAT я сделал, используя nftables + flow offload ( статья на Хабре ), для этого взял Ubuntu 20.04. Изначально я поставил самый свежий драйвер i40e от Intel на sourceforge. И только потом вспомнил, что на этом драйвере дропы выросли многократно. Итоговый вариант: включен HyperThreading, ubuntu 20.04, mitigations=off, драйвер i40e в комплекте с ядром, кол-во очередей равно ядрам+HT, ethtool -C rx tx 50. Трафик на одном интерфейсе разделенный на 2 влана (влан1- наша сеть, влан2 - в сторону бордера/аплинков). Поскольку очереди привязаны к local numa, получается, второй процессор отдыхает совсем. За последние сутки дропов 0 при пике в 26,57 гбит/с и 3,39 мппс в каждую сторону. При этом минимальный idle у задействованных ядер примерно 82% . Напомню , cpu E5-2690v4 Благодарю за ценные советы автора статьи на Хабре.

Я что то подумал, что речь изначально про поток сетевой карты, а не поток трафика от клиента. Поэтому и спросил, как определили, что проблема с потоком. В таком случае не факт, что проблема вообще в этом PC-маршрутизаторе.

Как вы определили, что проблема с одним из потоков-очередью?

Думаю, вам стоит сюда выложить выводы всего тюнинга проблемного интерфейса: ethtool -k , -g , -l , -S заодно и cat /proc/interrupts | grep <ifname> С этим потоком только сейчас появились проблемы или всегда были? Что явилось триггером начала проблемы?

Не совсем понял, у вас проблемы только с 1 потоком (очередью)? с остальными все ок? Если да, то есть ли реально жалобы от клиентов?

Добрый день. Тюнили сетевую карту через ethtool (отключение оффлоадов, gro,tso,lro и прочее)?

Коллеги, вопрос не совсем про сплиттеры, но все же: есть у кого опыт СОРМ-2 на 40G интерфейсах, да еще и если производитель съемника (мфи в частности) не умеет принимать трафик на 40G интерфейсах? Могут только 10G интерфейсы использовать.

Я понимаю, что проблема редкая, да и мало кто на такой полосе трафика запускает все на штатном линуксе с conntrack, без всяких DPDK и прочих XDP. Поэтому осознаю, что однозначного ответа не получу, но коллективный разум может вывести на что то, что я еще не проверил. rx буферы выкручены на максимум (при меньших значениях были потери еще больше) под таймерами и частотой прерываний вы понимаете значения, которые можно выставить через ethtool -C ? механизм группировки пакетов в очереди , режим прерывания ядра, настройки таймингов планировщика - можете подробнее, про какие именно параметры вы говорите?

flow control отключен как со стороны сервера, так и со стороны коммутатора, куда он подключен.   В более современных доках от Intel пишут, что этот счетчик означает, что не успели опустошиться очереди сетевой карты. Пример

Счетчик rx_dropped. Его можно увидеть через ethtool -S

После статьи, ссылку на которую прислал sdy_moscow, я в первую очередь на них обратил внимание, потому что это единственное, что я не крутил. netdev_budget каким бы не выставлял, а 3-я колонка в softnet_stat все равно почуть увеличивается.