conrad Опубликовано 3 июля, 2017 · Жалоба Всем доброго времени суток! Имеется сервер Dell C6100 в качестве PPPoE браса, две головы Intel® Xeon® CPU L5630 2.13GHz, двух портовая интеловская карточка на чипсете 82576 (драйвер igb), на сервере установлены: FreeBSD 10.3-RELEASE, MPD version 5.8, BIND 9.9.9-P, HT отключен. Из тюнинга: /boot/loader.conf hw.igb.rxd=4096 hw.igb.txd=4096 hw.igb.max_interrupt_rate=32000 net.isr.defaultqlimit=4096 net.link.ifqmaxlen=10240 kern.maxusers=2048 net.add_addr_allfibs=0 /etc/sysctl.conf dev.igb.0.rx_processing_limit=4096 dev.igb.1.rx_processing_limit=4096 net.inet.ip.fastforwarding=1 net.inet.tcp.blackhole=2 net.inet.udp.blackhole=0 net.inet.icmp.icmplim=500 kern.ipc.soacceptqueue=1024 net.graph.recvspace=8388608 net.graph.maxdgram=8388608 kern.ipc.maxsockbuf=20971520 net.inet.ip.intr_queue_maxlen=8192 net.inet.tcp.recvbuf_auto=0 net.inet.tcp.sendbuf_auto=0 hw.igb.enable_aim=0 net.inet.tcp.sendspace=131072 net.inet.tcp.tso=0 CPU 0: 0.0% user, 0.0% nice, 0.8% system, 61.0% interrupt, 38.2% idle CPU 1: 1.2% user, 0.0% nice, 0.4% system, 7.1% interrupt, 91.3% idle CPU 2: 0.8% user, 0.0% nice, 0.0% system, 6.3% interrupt, 92.9% idle CPU 3: 0.4% user, 0.0% nice, 0.4% system, 8.7% interrupt, 90.6% idle CPU 4: 2.0% user, 0.0% nice, 0.4% system, 9.4% interrupt, 88.2% idle CPU 5: 3.1% user, 0.0% nice, 0.0% system, 11.4% interrupt, 85.4% idle CPU 6: 0.8% user, 0.0% nice, 0.8% system, 10.6% interrupt, 87.8% idle CPU 7: 0.4% user, 0.0% nice, 0.8% system, 9.4% interrupt, 89.4% idle Проблема заключается в том что как только число онлайн PPPoE сессий приблизилось к 2к(трафик в пике 700mbit/200mbit) брас стал ежедневно падать, в статусе процесса mpd наблюдаю umtxn. Подскажите пожалуйста, можно ли как то поправить ситуацию? Заранее благодарю за ответ. P.S.: Пробовал раскидывать прерывания от карточек по ядрам, толку нет. Очень сильно грузит ядро прерывание которое обслуживает нулевую очередь порта на котором поднимаются туннели(ядро 0 в показателях выше). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 3 июля, 2017 · Жалоба В сисцтл: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. #net.isr.bindthreads=1 # Bind netisr threads to CPUs net.route.netisr_maxqlen=1024 # maximum routing socket dispatch queue length net.inet.ip.intr_queue_maxlen=8192 # Maximum size of the IP input queue. Should be increased until net.inet.ip.intr_queue_drops is zero в лоадер: # NetISR net.isr.maxthreads="1024" # Use at most this many CPUs for netisr processing net.isr.bindthreads="1" # Bind netisr threads to CPUs. net.isr.defaultqlimit="16384" # Default netisr per-protocol, per-CPU queue limit if not set by protocol net.isr.maxqlimit="16384" # Maximum netisr per-protocol, per-CPU queue depth. net.inet.tcp.recvbuf_auto=0 net.inet.tcp.sendbuf_auto=0 net.inet.tcp.sendspace=131072 net.inet.tcp.tso=0 Это маршрутизируемого трафика вообще никак не касается. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 3 июля, 2017 · Жалоба Логирование в mpd выключено? В своё время наступил на похожие грабли на самой первой "10-ке" FreeBSD. Не знаю, что там не сдружилось у этой парочки, но отключение логирования заметно помогло. Посему забил на 10-ку и на все сервера с mpd ставлю только 9.3. Проблема заключается в том что как только число онлайн PPPoE сессий приблизилось к 2к(трафик в пике 700mbit/200mbit) брас стал ежедневно падать, в статусе процесса mpd ИМХО, уже многовато. Как первое, так и второе. "Священное число" - 70%.. Во всяком случае, в плане трафика. У себя в такой ситуации запускаю 2..3...и т.д. NAS. Если машины более-менее одинаковые по железу/памяти, то нагрузка на каждую распределяется вполне ровно. P.S.: Пробовал раскидывать прерывания от карточек по ядрам, толку нет. Очень сильно грузит ядро прерывание которое обслуживает нулевую очередь порта на котором поднимаются туннели(ядро 0 в показателях выше). А PPPoE вроде как и теоретически не раскидать по ядрам, т.к. L2. Может и ошибаюсь, но где-то об этом читал.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
conrad Опубликовано 3 июля, 2017 · Жалоба В сисцтл: net.isr.dispatch=deferred # direct / hybrid / deffered // Interrupt handling via multiple CPU, but with context switch. #net.isr.bindthreads=1 # Bind netisr threads to CPUs net.route.netisr_maxqlen=1024 # maximum routing socket dispatch queue length net.inet.ip.intr_queue_maxlen=8192 # Maximum size of the IP input queue. Should be increased until net.inet.ip.intr_queue_drops is zero в лоадер: # NetISR net.isr.maxthreads="1024" # Use at most this many CPUs for netisr processing net.isr.bindthreads="1" # Bind netisr threads to CPUs. net.isr.defaultqlimit="16384" # Default netisr per-protocol, per-CPU queue limit if not set by protocol net.isr.maxqlimit="16384" # Maximum netisr per-protocol, per-CPU queue depth. net.inet.tcp.recvbuf_auto=0 net.inet.tcp.sendbuf_auto=0 net.inet.tcp.sendspace=131072 net.inet.tcp.tso=0 Это маршрутизируемого трафика вообще никак не касается. Спасибо, попробую.. А что скажете на счет этого? Говорят на 9.3 проблемы нет.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 3 июля, 2017 · Жалоба Ничего не скажу, мне что мпд5 что 9х не шибко инетересно. Кажется тут кто то говорил то ли бинд то ли ещё что то с подобных сервисов держать на брасе зло, ибо оно на каждый интерфейс пытается биндится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
myth Опубликовано 3 июля, 2017 · Жалоба snmp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 3 июля, 2017 · Жалоба snmp Очень и очень возможно! Кстати, как ему (snmpd) запретить "видеть" ng и vlan интерфейсы, кто-нибудь знает? Мне так и не удалось это побороть.. А без snmpd NAS становится "чёрным ящиком".. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
conrad Опубликовано 3 июля, 2017 (изменено) · Жалоба Ничего не скажу, мне что мпд5 что 9х не шибко инетересно. Кажется тут кто то говорил то ли бинд то ли ещё что то с подобных сервисов держать на брасе зло, ибо оно на каждый интерфейс пытается биндится. bind прибит к интерфейсам (listen-on { 127.0.0.1; 10.17.0.100; };) неужели все равно будет дергать другие интерфейсы? snmp Отключен давно, так как хорошо грузил проц. Снимаю стату по трафику с порта коммутатора к которому подключен брас. Изменено 3 июля, 2017 пользователем conrad Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 3 июля, 2017 · Жалоба bind прибит к интерфейсам (listen-on { 127.0.0.1; 10.17.0.100; };) неужели все равно будет дергать другие интерфейсы? snmp Отключен давно, так как хорошо грузил проц. Снимаю стату по трафику с порту коммутатора к которому подключен брас. А это Логирование в mpd выключено? В своё время наступил на похожие грабли на самой первой "10-ке" FreeBSD. Не знаю, что там не сдружилось у этой парочки, но отключение логирования заметно помогло. ?И ещё - NAT на NAS-е есть, или вынесен? Если есть, то могут быть и его "плоды". У меня почему-то NAT FreeBSD (ipfw) так и "не получился". Вынес на машину с CentOS и забыл. P.S. Снимаю стату по трафику с порту коммутатора к которому подключен брас. А CPU Load?? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 3 июля, 2017 · Жалоба bind прибит к интерфейсам (listen-on { 127.0.0.1; 10.17.0.100; };) неужели все равно будет дергать другие интерфейсы? Я мог перепутать. В любом случае я бы выносил такие сервисы, если только это не специфичные условия когда нас где то на точке, аплинк херовый, и места под ещё одну железку нет и не целесообразно. Мне так и не удалось это побороть.. А без snmpd NAS становится "чёрным ящиком".. Радиус акаунтинг, мпд сам тоже какой то интерфейс предоставляет. Может посмотреть что то из портов, в базе как правило или не самое новое или какое то дерьмо типа сендмыла которое никому не нужно и даром. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
conrad Опубликовано 3 июля, 2017 · Жалоба Логирование в mpd выключено? В своё время наступил на похожие грабли на самой первой "10-ке" FreeBSD. Не знаю, что там не сдружилось у этой парочки, но отключение логирования заметно помогло. Посему забил на 10-ку и на все сервера с mpd ставлю только 9.3. Проблема заключается в том что как только число онлайн PPPoE сессий приблизилось к 2к(трафик в пике 700mbit/200mbit) брас стал ежедневно падать, в статусе процесса mpd ИМХО, уже многовато. Как первое, так и второе. "Священное число" - 70%.. Во всяком случае, в плане трафика. У себя в такой ситуации запускаю 2..3...и т.д. NAS. Если машины более-менее одинаковые по железу/памяти, то нагрузка на каждую распределяется вполне ровно. P.S.: Пробовал раскидывать прерывания от карточек по ядрам, толку нет. Очень сильно грузит ядро прерывание которое обслуживает нулевую очередь порта на котором поднимаются туннели(ядро 0 в показателях выше). А PPPoE вроде как и теоретически не раскидать по ядрам, т.к. L2. Может и ошибаюсь, но где-то об этом читал.. Логирование mpd выключено, так как даже на 1к сессий лог будет расти с космической скоростью. bind прибит к интерфейсам (listen-on { 127.0.0.1; 10.17.0.100; };) неужели все равно будет дергать другие интерфейсы? snmp Отключен давно, так как хорошо грузил проц. Снимаю стату по трафику с порту коммутатора к которому подключен брас. А это Логирование в mpd выключено? В своё время наступил на похожие грабли на самой первой "10-ке" FreeBSD. Не знаю, что там не сдружилось у этой парочки, но отключение логирования заметно помогло. ?И ещё - NAT на NAS-е есть, или вынесен? Если есть, то могут быть и его "плоды". У меня почему-то NAT FreeBSD (ipfw) так и "не получился". Вынес на машину с CentOS и забыл. P.S. Снимаю стату по трафику с порту коммутатора к которому подключен брас. А CPU Load?? NATа на NAS-е нет, он на линуксе, CPU не снимаю и думаю что его можно снимать не только с помощью snmp но и каких то скриптов которые парсят значения с top. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 3 июля, 2017 · Жалоба Переходите на accel-ppp))) Сам раньше сидел на мопеде) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 3 июля, 2017 · Жалоба Работает годами без малейших проблем, онлайн максимально был около 4К. Фря - 9-ка. Мать - десктопная. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 4 июля, 2017 · Жалоба Работает годами без малейших проблем, онлайн максимально был около 4К. Фря - 9-ка. Мать - десктопная. ... проц. Pentium-3, сетевая RTL8239, трафик ~3Гб/с., 300K pps ;-) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
andryas Опубликовано 4 июля, 2017 · Жалоба ... проц. Pentium-3, сетевая RTL8239, трафик ~3Гб/с., 300K pps ;-) Ну, с таким "сервером", да, будут проблемы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 6 июля, 2017 (изменено) · Жалоба RTL8239, трафик ~3Гб/с. эм, а ничего, что чипсет рилтека 8239 он каг бэ... 100 мегабитный, ничего? как бы в пенек третий уже и так никто не поверил, но ради приличия хотя бы гиговй какой-то втулили, раз уж на стеб потянуло. Изменено 6 июля, 2017 пользователем GrandPr1de Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 6 июля, 2017 (изменено) · Жалоба Да это троллинг , ну никак на P3 не выжать 3 гбита , причем как заметил GrandPr1de , на FE)) Изменено 6 июля, 2017 пользователем roysbike Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
GrandPr1de Опубликовано 6 июля, 2017 · Жалоба Да это троллинг , ну никак на P3 не выжать 3 гбита , причем как заметил GrandPr1de , на FE)) ну чё... запинговать локалхост до смерти тоже ведь "траффик" ТС, а покажите конфигу мпд. У меня в своё время грабли были из-за нетфлоу... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
AlKov Опубликовано 6 июля, 2017 · Жалоба RTL8239, трафик ~3Гб/с. эм, а ничего, что чипсет рилтека 8239 он каг бэ... 100 мегабитный, ничего? как бы в пенек третий уже и так никто не поверил, но ради приличия хотя бы гиговй какой-то втулили, раз уж на стеб потянуло. Для того и написано было так явно, чтобы обратить внимание на комментируемую информацию. Я так понимаю, предыдущая строчка ни у кого сомнений не вызвала? ;-) Ну что ж.. Прокомментирую ещё раз, грубо в лоб - :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
roysbike Опубликовано 6 июля, 2017 · Жалоба Мне кажется дело в кабеле между коммутатором и сервером. Вот видео как это поправить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
conrad Опубликовано 7 июля, 2017 (изменено) · Жалоба Да это троллинг , ну никак на P3 не выжать 3 гбита , причем как заметил GrandPr1de , на FE)) ну чё... запинговать локалхост до смерти тоже ведь "траффик" ТС, а покажите конфигу мпд. У меня в своё время грабли были из-за нетфлоу... startup: # enable TCP-Wrapper (hosts_access(5)) to block unfriendly clients #set global enable tcp-wrapper # configure the console old way set user xxxxxx xxxxx xxxxxx set console self 10.17.0.100 5005 set console open # Radius CoA/PoD set radsrv peer xxxxx xxxxxxx set radsrv self 10.17.0.100 3799 set radsrv open default: # load pptp_server load pppoe_server load /usr/local/etc/mpd5/filters.conf filters pppoe_server: create bundle template B set iface idle 0 set iface enable tcpmssfix proxy-arp set ipcp no vjcomp set ipcp ranges 10.17.0.100 ippool pool1 set ipcp dns 10.17.0.100 ### PPPOE on igb1 create link template L pppoe set link action bundle B set pppoe acname "bras1" set pppoe iface igb1 set pppoe service "*" set pppoe mac-format unix-like load server_common ### PPPOE on vlan2 create link template L1 pppoe set link action bundle B set pppoe acname "bras1" set pppoe iface vlan2 set pppoe service "*" set pppoe mac-format unix-like load server_common ### PPPOE on vlan3 create link template L2 pppoe set link action bundle B set pppoe acname "bras1" set pppoe iface vlan3 set pppoe service "*" set pppoe mac-format unix-like load server_common server_common: set link no pap eap set link yes chap-md5 set link keep-alive 20 60 set link enable incoming set link no acfcomp protocomp load radius radius: set radius server xxxxxx xxxxxx 1812 1813 set radius config /etc/radius.conf set radius retries 3 set radius timeout 60 set auth acct-update 300 set auth enable radius-auth set auth enable radius-acct set auth disable internal Влан интерфейсов в конфиге больше, не стал выводить все, конфигурация на них аналогичная. Netflow на BRAS-е нет, он на линуховом гейте. Изменено 7 июля, 2017 пользователем conrad Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
YuryD Опубликовано 7 июля, 2017 (изменено) · Жалоба Очень и очень возможно! Кстати, как ему (snmpd) запретить "видеть" ng и vlan интерфейсы, кто-нибудь знает? Мне так и не удалось это побороть.. А без snmpd NAS становится "чёрным ящиком".. Как-то поборол в древние времена, давно была траблема с загрузкой CPU при частых реконнектах к мпд. При падении и возникновении новых Ng. вроде поставил и настроил bsnp. И у мртг заставил брать не список интерфейсов, а их количество в общем, там и отписался в форуме про сей грязный метод. Изменено 7 июля, 2017 пользователем YuryD Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
terrible Опубликовано 11 июля, 2017 · Жалоба IPv6 в ядре активирован? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
conrad Опубликовано 13 июля, 2017 · Жалоба IPv6 в ядре активирован? Наоборот, выключен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
conrad Опубликовано 13 июля, 2017 · Жалоба Выкинул часть пользователей с проблемного браса (umtxn после 1.8к пользователей) на другой брас аналогичной конфигурации (и по железу и по софту), так второй брас начал заваливаться каждые сутки с той же проблемой но уже при количестве сессий ~500 Попробовал последовать сообщению dadv - обновился с 10.3-release до stable и обновил mpd до 5.8_2, пока ничего не патчил. Второй брас живет уже 3 день, подожду еще чуть и если все ок то проделаю те же действия с первым брасом. Всем спасибо за советы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...