Перейти к содержимому
Калькуляторы

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Изменено пользователем vlad11

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Нат на чём?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, это сам 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 секунд

Изменено пользователем 220B

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

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

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.