[conrad]

Всем доброго времени суток! Имеется сервер 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 в показателях выше).

[Ivan_83]

В сисцтл:

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

Это маршрутизируемого трафика вообще никак не касается.

[AlKov]

Логирование в mpd выключено?

В своё время наступил на похожие грабли на самой первой "10-ке" FreeBSD. Не знаю, что там не сдружилось у этой парочки, но отключение логирования заметно помогло.

Посему забил на 10-ку и на все сервера с mpd ставлю только 9.3.

Проблема заключается в том что как только число онлайн PPPoE сессий приблизилось к 2к(трафик в пике 700mbit/200mbit) брас стал ежедневно падать, в статусе процесса mpd

ИМХО, уже многовато. Как первое, так и второе. "Священное число" - 70%.. Во всяком случае, в плане трафика.

У себя в такой ситуации запускаю 2..3...и т.д. NAS. Если машины более-менее одинаковые по железу/памяти, то нагрузка на каждую распределяется вполне ровно.

P.S.: Пробовал раскидывать прерывания от карточек по ядрам, толку нет. Очень сильно грузит ядро прерывание которое обслуживает нулевую очередь порта на котором поднимаются туннели(ядро 0 в показателях выше).

А PPPoE вроде как и теоретически не раскидать по ядрам, т.к. L2.

Может и ошибаюсь, но где-то об этом читал..

[conrad]

В сисцтл:

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 проблемы нет..

[Ivan_83]

Ничего не скажу, мне что мпд5 что 9х не шибко инетересно.

Кажется тут кто то говорил то ли бинд то ли ещё что то с подобных сервисов держать на брасе зло, ибо оно на каждый интерфейс пытается биндится.

[myth]

snmp

[AlKov]

snmp

Очень и очень возможно!

Кстати, как ему (snmpd) запретить "видеть" ng и vlan интерфейсы, кто-нибудь знает?

Мне так и не удалось это побороть.. А без snmpd NAS становится "чёрным ящиком"..

[conrad]

Ничего не скажу, мне что мпд5 что 9х не шибко инетересно.

Кажется тут кто то говорил то ли бинд то ли ещё что то с подобных сервисов держать на брасе зло, ибо оно на каждый интерфейс пытается биндится.

 

bind прибит к интерфейсам (listen-on { 127.0.0.1; 10.17.0.100; };) неужели все равно будет дергать другие интерфейсы?

 

snmp

 

Отключен давно, так как хорошо грузил проц. Снимаю стату по трафику с порта коммутатора к которому подключен брас.

Edited July 3, 2017 by conrad

[AlKov]

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??

[Ivan_83]

bind прибит к интерфейсам (listen-on { 127.0.0.1; 10.17.0.100; };) неужели все равно будет дергать другие интерфейсы?

Я мог перепутать.

В любом случае я бы выносил такие сервисы, если только это не специфичные условия когда нас где то на точке, аплинк херовый, и места под ещё одну железку нет и не целесообразно.

 

Мне так и не удалось это побороть.. А без snmpd NAS становится "чёрным ящиком"..

Радиус акаунтинг, мпд сам тоже какой то интерфейс предоставляет.

Может посмотреть что то из портов, в базе как правило или не самое новое или какое то дерьмо типа сендмыла которое никому не нужно и даром.

[conrad]

Логирование в 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.

[roysbike]

Переходите на accel-ppp))) Сам раньше сидел на мопеде)

[andryas]

Работает годами без малейших проблем, онлайн максимально был около 4К. Фря - 9-ка. Мать - десктопная.

[AlKov]

Работает годами без малейших проблем, онлайн максимально был около 4К. Фря - 9-ка. Мать - десктопная.

... проц. Pentium-3, сетевая RTL8239, трафик ~3Гб/с., 300K pps ;-)

[andryas]

... проц. Pentium-3, сетевая RTL8239, трафик ~3Гб/с., 300K pps ;-)

 

Ну, с таким "сервером", да, будут проблемы.

[GrandPr1de]

RTL8239, трафик ~3Гб/с.

эм, а ничего, что чипсет рилтека 8239 он каг бэ... 100 мегабитный, ничего?

как бы в пенек третий уже и так никто не поверил, но ради приличия хотя бы гиговй какой-то втулили, раз уж на стеб потянуло.

Edited July 6, 2017 by GrandPr1de

[roysbike]

Да это троллинг , ну никак на P3 не выжать 3 гбита , причем как заметил GrandPr1de , на FE))

Edited July 6, 2017 by roysbike

[GrandPr1de]

Да это троллинг , ну никак на P3 не выжать 3 гбита , причем как заметил GrandPr1de , на FE))

ну чё... запинговать локалхост до смерти

тоже ведь "траффик"

 

ТС, а покажите конфигу мпд.

У меня в своё время грабли были из-за нетфлоу...

[AlKov]

RTL8239, трафик ~3Гб/с.

эм, а ничего, что чипсет рилтека 8239 он каг бэ... 100 мегабитный, ничего?

как бы в пенек третий уже и так никто не поверил, но ради приличия хотя бы гиговй какой-то втулили, раз уж на стеб потянуло.

Для того и написано было так явно, чтобы обратить внимание на комментируемую информацию.

Я так понимаю, предыдущая строчка ни у кого сомнений не вызвала? ;-)

Ну что ж.. Прокомментирую ещё раз, грубо в лоб -

:)

[roysbike]

Мне кажется дело в кабеле между коммутатором и сервером. Вот видео как это поправить.

 

[conrad]

Да это троллинг , ну никак на 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-е нет, он на линуховом гейте.

Edited July 7, 2017 by conrad

[YuryD]

Очень и очень возможно!

Кстати, как ему (snmpd) запретить "видеть" ng и vlan интерфейсы, кто-нибудь знает?

Мне так и не удалось это побороть.. А без snmpd NAS становится "чёрным ящиком"..

 

Как-то поборол в древние времена, давно была траблема с загрузкой CPU при частых реконнектах к мпд. При падении и возникновении новых Ng. вроде поставил и настроил bsnp. И у мртг заставил брать не список интерфейсов, а их количество в общем, там и отписался в форуме про сей грязный метод.

Edited July 7, 2017 by YuryD

[terrible]

IPv6 в ядре активирован?

[conrad]

IPv6 в ядре активирован?

 

Наоборот, выключен.

[conrad]

Выкинул часть пользователей с проблемного браса (umtxn после 1.8к пользователей) на другой брас аналогичной конфигурации (и по железу и по софту), так второй брас начал заваливаться каждые сутки с той же проблемой но уже при количестве сессий ~500 Попробовал последовать сообщению dadv - обновился с 10.3-release до stable и обновил mpd до 5.8_2, пока ничего не патчил. Второй брас живет уже 3 день, подожду еще чуть и если все ок то проделаю те же действия с первым брасом. Всем спасибо за советы.