hizel Posted March 28, 2014 · Report post 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
rpra Posted March 28, 2014 · Report post И эти люди хаят некротик facepalm Зато можно выучить тучу умных слов и параметров Share this post Link to post Share on other sites
ilovemoney Posted March 28, 2014 · Report post Ваш некротик такое же г.. Есть нормальные брасы на циске, е, джунипере на ху в конце концов Share this post Link to post Share on other sites
alibek Posted March 28, 2014 · Report post Есть нормальные брасы на циске, е, джунипере на ху в конце концов На серверах тоже есть нормальные BRAS. Правда для этого чаще используют все же Linux, а не FreeBSD. Share this post Link to post Share on other sites
vlad11 Posted March 28, 2014 (edited) · Report post 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 Share this post Link to post Share on other sites
hizel Posted March 28, 2014 · Report post pptp/pppoe нет, netgraph только для ng_netflow Share this post Link to post Share on other sites
Ivan_83 Posted March 28, 2014 · Report post А если нетфлоу убрать, работает? Нат на чём? Share this post Link to post Share on other sites
hizel Posted April 1, 2014 · Report post netflow убирать не пробовал, nat - kernel ipfw nat Share this post Link to post Share on other sites
hizel Posted April 30, 2014 · Report post Рабочая гипотеза: драйвер работает неправильно тогда когда трафика впритык к скорости порта. Было 100мбит - умирал, стало 1Гб и трафика ~200мбит и ни единого разрыва! Share this post Link to post Share on other sites
hizel Posted October 8, 2014 · Report post Откидываем предудущую гипотезу, вводная для новой: 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
vlad11 Posted October 8, 2014 · Report post Если libalias встает колом смотрите тюнинги FreeBSD. Там нужно поднять значения некоторых переменных и пересобрать мир-ядро. Share this post Link to post Share on other sites
hizel Posted October 21, 2014 · Report post Нет, это сам libalias превращается в тыкву, pmcstat -TS instructions -w 1 показывает в top-е _mtx_lock_sleep LibAliasOut . Выкидываю ipfw nat на мороз, здравствуй pf. Share this post Link to post Share on other sites
220B Posted December 1, 2014 (edited) · Report post Нет, это сам 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 Share this post Link to post Share on other sites
hizel Posted December 3, 2014 · Report post Перешел на pf. Я смотрел код libalias и он дубовый, например один mutex на всю хеш-таблицу nat. Не увидел там крутилок, чтобы как-то исправить не трогая код. Share this post Link to post Share on other sites
