FreeBSD 9 igb в случайный момент превращает BRAS в тыкву

[hizel]

FreeBSD 9.2 с igb(2.3.10) железом I350 и 82576 на двух разных BRAS с функциями netflow/shaping/nat при трафике близкой к скорости порта ~100Mbit и 10-20kpps может внезапно превратится в тыкву. LA резко растет, в top -SP процесс прерываний(intr) постепенно откусывает все ядра, но кол-во прерываний/сек вместо роста тоже уменьшается в ноль и кантупер перестает реагировать на любые раздражители, выглядит как зависание. Как только отрываешь сосок аплинка в инторнеты ~10-20сек железка приходит в себя и работает штатно, возвращаешь сосок обратно ~20-30 сек рост LA и тыква снова. Крутил вертел всякие sysctl которые рекомендуются для igb но неделю или месяц BRAS может стоять как скала и вдруг в пятницу 17:00 опять упасть кверху лапами. Два разных BRAS-а одинаково, но не одновременно. Разное железо.

 

Пару раз решалось десятком перезагрузок, с жанглированием параметров sysctl. Вот, думалось, нашлась магическая комбинация, но через неделю\месяц опять тыква. Последний раз на BRAS 82576 аплинк выткнул из igb и внедрил через набортный re, но это не серьезно.

 

Думаю в следующий аврал попробовать потыкать net.isr.dispatch в hybrid.

 

 

Посмотрел на форуме, что то у кого примерно такие же проблемы то ли не решили проблему то ли решили но не написали.

 

/boot/loader.conf

hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.max_interrupt_rate=32000
net.link.ifqmaxlen=10240
net.isr.defaultqlimit=4096
net.graph.maxdata=4096
net.graph.maxalloc=8192

/etc/sysctl.conf

net.inet.udp.blackhole=1
dev.igb.0.rx_processing_limit=4096
dev.igb.1.rx_processing_limit=4096
dev.igb.2.rx_processing_limit=4096
dev.igb.3.rx_processing_limit=4096
net.inet.udp.blackhole=1
kern.maxfiles=204800
kern.ipc.maxsockets=262144
net.route.netisr_maxqlen=4096
kern.ipc.nmbclusters=400000
kern.ipc.maxsockbuf=83886080
net.inet.udp.recvspace=65535

 

Ядро GENEREC с вкомпиленым IPFIREWALL и IPFIREWALL_DEFAULT_TO_ACCEPT

[rpra]

И эти люди хаят некротик facepalm

Зато можно выучить тучу умных слов и параметров

[ilovemoney]

Ваш некротик такое же г..

Есть нормальные брасы на циске, е, джунипере на ху в конце концов

[alibek]

Есть нормальные брасы на циске, е, джунипере на ху в конце концов

На серверах тоже есть нормальные BRAS.

Правда для этого чаще используют все же Linux, а не FreeBSD.

[vlad11]

FreeBSD 9.2 с igb(2.3.10) железом I350 и 82576 на двух разных BRAS с функциями netflow/shaping/nat при трафике близкой к скорости порта ~100Mbit и 10-20kpps может внезапно превратится в тыкву. LA резко растет, в top -SP процесс прерываний(intr) постепенно откусывает все ядра, но кол-во прерываний/сек вместо роста тоже уменьшается в ноль и кантупер перестает реагировать на любые раздражители, выглядит как зависание. Как только отрываешь сосок аплинка в инторнеты ~10-20сек железка приходит в себя и работает штатно, возвращаешь сосок обратно ~20-30 сек рост LA и тыква снова. Крутил вертел всякие sysctl которые рекомендуются для igb но неделю или месяц BRAS может стоять как скала и вдруг в пятницу 17:00 опять упасть кверху лапами. Два разных BRAS-а одинаково, но не одновременно. Разное железо.

 

 

Включите atop. и дайте файлик с последними данными перед падением.

 

Поднимите значения для Нетграфа

net.graph.recvspace=2048000
net.graph.maxdgram=2048000

Edited March 28, 2014 by vlad11

[hizel]

pptp/pppoe нет, netgraph только для ng_netflow

[Ivan_83]

А если нетфлоу убрать, работает?

Нат на чём?

[hizel]

netflow убирать не пробовал, nat - kernel ipfw nat

[hizel]

Рабочая гипотеза: драйвер работает неправильно тогда когда трафика впритык к скорости порта. Было 100мбит - умирал, стало 1Гб и трафика ~200мбит и ни единого разрыва!

[hizel]

Откидываем предудущую гипотезу, вводная для новой: https://groups.google.com/forum/#!msg/uafug/oVPrZRdE5eU/W_TFk9ifaSIJ

 

Тупой libalias(ng_nat, ipfw nat, natd) на большом кол-ве nat сессий и нескольких queue у сетевой карты встает колом. Пока трафика не много устанвил hw.igb.num_queues=1 в /boot/loader.conf

[vlad11]

Если libalias встает колом смотрите тюнинги FreeBSD.

Там нужно поднять значения некоторых переменных и пересобрать мир-ядро.

[hizel]

Нет, это сам libalias превращается в тыкву, pmcstat -TS instructions -w 1 показывает в top-е _mtx_lock_sleep LibAliasOut . Выкидываю ipfw nat на мороз, здравствуй pf.

[220B]

Нет, это сам libalias превращается в тыкву, pmcstat -TS instructions -w 1 показывает в top-е _mtx_lock_sleep LibAliasOut . Выкидываю ipfw nat на мороз, здравствуй pf.

Удалось понять корень проблемы или благополучно перешли на pf nat ?

 

P.S. проапгрейдил с 10.0 до 10.1, но воз и ныне там

pmcstat -TS instructions -w 1<br>

SAMP IMAGE      FUNCTION             CALLERS
43.3 kernel     __mtx_lock_sleep     LibAliasIn:37.5 LibAliasOut:5.7
18.0 kernel     _FindLinkIn          FindUdpTcpIn
 7.3 kernel     ipfw_chk             ipfw_check_packet
 4.3 libc.so.7  bsearch
 3.9 kernel     rn_match             ipfw_lookup_table:3.4 rtalloc1_fib:0.5
 2.4 kernel     sched_idletd         fork_exit

vmstat -m | grep alias | tr -s ' ' | cut -d ' ' -f 4

102616K

 

Это при том что трафика на сервере почти нет и подобная эскалация наступает стремительно в течении 5-30 секунд

Edited December 3, 2014 by 220B

[hizel]

Перешел на pf. Я смотрел код libalias и он дубовый, например один mutex на всю хеш-таблицу nat. Не увидел там крутилок, чтобы как-то исправить не трогая код.