Jump to content
Калькуляторы

Виснет MPD

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

Share this post


Link to post
Share on other sites

В сисцтл:

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

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

Share this post


Link to post
Share on other sites

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

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

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

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

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

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

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

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

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

Share this post


Link to post
Share on other sites

В сисцтл:

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

snmp

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

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

 

snmp

 

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

Edited by conrad

Share this post


Link to post
Share on other sites

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

Share this post


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

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

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

 

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

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites
RTL8239, трафик ~3Гб/с.

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

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

Edited by GrandPr1de

Share this post


Link to post
Share on other sites

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

Edited by roysbike

Share this post


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

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

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

 

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

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

Share this post


Link to post
Share on other sites
RTL8239, трафик ~3Гб/с.

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

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

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

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

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

:)

Share this post


Link to post
Share on other sites

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

 

Share this post


Link to post
Share on other sites
Да это троллинг , ну никак на 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 by conrad

Share this post


Link to post
Share on other sites

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

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

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

 

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

Edited by YuryD

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this