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