Jump to content
Калькуляторы

John_obn

Активный участник
  • Content Count

    253
  • Joined

  • Last visited

About John_obn

  • Rank
    Студент

Контакты

  • ICQ
    170034045

Информация

  • Пол
    Не определился

Recent Profile Visitors

2405 profile views
  1. Решил свою проблему, описанную выше. Для начала вынес роль бордера на 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 Благодарю за ценные советы автора статьи на Хабре.
  2. Я что то подумал, что речь изначально про поток сетевой карты, а не поток трафика от клиента. Поэтому и спросил, как определили, что проблема с потоком. В таком случае не факт, что проблема вообще в этом PC-маршрутизаторе.
  3. Как вы определили, что проблема с одним из потоков-очередью?
  4. Думаю, вам стоит сюда выложить выводы всего тюнинга проблемного интерфейса: ethtool -k , -g , -l , -S заодно и cat /proc/interrupts | grep <ifname> С этим потоком только сейчас появились проблемы или всегда были? Что явилось триггером начала проблемы?
  5. Не совсем понял, у вас проблемы только с 1 потоком (очередью)? с остальными все ок? Если да, то есть ли реально жалобы от клиентов?
  6. Добрый день. Тюнили сетевую карту через ethtool (отключение оффлоадов, gro,tso,lro и прочее)?
  7. Коллеги, вопрос не совсем про сплиттеры, но все же: есть у кого опыт СОРМ-2 на 40G интерфейсах, да еще и если производитель съемника (мфи в частности) не умеет принимать трафик на 40G интерфейсах? Могут только 10G интерфейсы использовать.
  8. Я понимаю, что проблема редкая, да и мало кто на такой полосе трафика запускает все на штатном линуксе с conntrack, без всяких DPDK и прочих XDP. Поэтому осознаю, что однозначного ответа не получу, но коллективный разум может вывести на что то, что я еще не проверил. rx буферы выкручены на максимум (при меньших значениях были потери еще больше) под таймерами и частотой прерываний вы понимаете значения, которые можно выставить через ethtool -C ? механизм группировки пакетов в очереди , режим прерывания ядра, настройки таймингов планировщика - можете подробнее, про какие именно параметры вы говорите?
  9. flow control отключен как со стороны сервера, так и со стороны коммутатора, куда он подключен.   В более современных доках от Intel пишут, что этот счетчик означает, что не успели опустошиться очереди сетевой карты. Пример
  10. Счетчик rx_dropped. Его можно увидеть через ethtool -S
  11. После статьи, ссылку на которую прислал sdy_moscow, я в первую очередь на них обратил внимание, потому что это единственное, что я не крутил. netdev_budget каким бы не выставлял, а 3-я колонка в softnet_stat все равно почуть увеличивается.
  12. Дело оказалось не в NAT. Я переводил временно NAT на BRASы, idle повышался на 10%, но дропы на ens6 никуда не уходили :( Сегодня еще раз перенесу NAT на BRASы, но уже будем спрашивать у абонентов, стало ли лучше по ощущениям. Потому что в прошлый раз пришлось через какое то время вернуть NAT на бордеры, т.к. по магистралям трафик неоптимально раскидался и в итоге один из междугородних каналов загрузился почти в полку.
  13. Весь транзитный трафик серых адресов уходил на xt_NAT, это подтверждалось мониторингом кол-ва записей conntrack, а также делал флаш таблицы conntrack. Единственное, потом появлялось порядка 30 записей, относящихся к локальному трафику бордера (bgp сессии в основном). Их не стал убирать из conntrack, подумав, что они не дают никакой нагрузки. Да, иначе дропы были больше, это уже давно выставленный параметр. По мере роста трафика увеличивался до максимума. $ ethtool -g ens6 Ring parameters for ens6: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096   Хмм..из-за 2 процессоров? Как бороться, кроме перехода на 1 процессор? Год или два назад значение было больше нуля, уже не помню сколько, и тогда начинали расти дропы, после этого довел до нуля и дропы прекратились. На сколько я понимаю, современные драйверы от intel и работают через софтовые прерывания? Или я ошибаюсь? За статью огромная благодарность, ранее на нее не натыкался, но много доков по прерываниям и работе сети изучил. Порядка 95% этого уже знал, но из этой статьи почерпнул и новое, проверю в ЧНН некоторые параметры, в частности softnet_stat. В выводе третий столбец не пустой, но и инкремент не сильно большой. Буду смотреть в момент, когда дропы будут расти.
  14. Судя по графикам, переход на xt_NAT не помог никак. Либо нагрузка от NAT не на столько значительна относительно лукапа таблицы маршрутизации и приема передачи пакетов на сетевых картах, либо все вместе дают такую картину и упираются в пределы чего то. Скажите, пожалуйста, свое мнение: ведь idle у ядер не становится меньше 18-19%, значит запас по производительности процессора есть, верно? Допускаю, что в моменты берстов idle может и в 0 уходить. Почему все таки возникают rx_dropped в таком количестве? Может какой то тип трафика дропается, jumbo там не летают - уже проверял. Rx_dropped - судя по докам, связано с выгребанием пакетов из очередей сетевой карты. Может не успевают очереди опустошиться...но почему? ethtool -c rx-usecs tx-usecs уже давно выставлены в 0, то есть прерывания генерятся как только так сразу. Если упирается в производительность сервера, хотелось бы понять в какой именно части. Смена conntrack на xt_NAT наводит на мысль о том, что вынос NAT на отдельный тазик может не помочь. Понимаю, что не попробуешь, не поймешь, просто дорогой тест выйдет, если причина в чем то другом.
  15. Если честно, это второй раз, когда приходится иметь дело с AppArmor. До этого на наших серверах приложений или роутеров ни разу AppArmor не мешал. Поэтому, от случая к случаю.   Не знаю, в чем несекурность, но на той же машине работал ipt_NETFLOW и таких проблем не было. А ведь делают они одно и то же, отправляют netflow на коллектор.