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