Jump to content

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

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

Share this post


Link to post
Share on other sites

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

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

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

Share this post


Link to post
Share on other sites

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 by vlad11

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Откидываем предудущую гипотезу, вводная для новой: 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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Нет, это сам 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 by 220B

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.