Добрый день.
Есть себе машина на freebsd 8.4 stable\mpd 5.6, работает около 240 дней, все ок.
Наработки по тюнингу были использвоны в новой машине на freebsd 10\mpd 5.7. Пересобрал мир\ядро,
проработала машина недели 2 и климануло mpd5. r26* билд freebsd10-stable там был.
Климануло точно известно с сообщением в дмесг
kernel: sonewconn: pcb 0xfffff8005927*: Listen queue overflow: 4 already in queue awaiting acceptance (500 occurrences) Демон климануло так, что рестартился он долго. После рестарта наблюдал не совсем объяснимые потери
пакетов через туннель, поэтому решил перезагрузить машину и заодно пересобрать ядро и мир, да увеличить kern.ipc.somaxconn до 2048 не особенно понимая почему лимит мог быть исчерпан.
Через несколько дней полета такой машины
uname -a
FreeBSD nas02.st.su 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271303M: Tue Sep 9 11:52:45 FET 2014 root@nas02.st.su:/usr/obj/usr/src/sys/sin-09092014 amd64
root@nas02:~ # mpd5 -v
Version 5.7 (root@10amd64-default-job-22 19:26 12-Jun-2014)
В мпд включены как pptp, так l2tp, так и pppoe демоны и вебка. 1024 активных очереди? на 5006 порту как раз вебка мпд.
Смотрю на машине с 8.4bsd\5.6mpd
netstat -LAan
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb Proto Listen Local Address
ffffff00d5a45760 tcp4 0/0/128 ip.2215
ffffff00c4bd4b10 tcp4 0/0/2 ip.1723
ffffff00c6015000 tcp4 0/0/128 ip.5006
ffffff006c637760 tcp4 0/0/2 127.0.0.1.5005
ffffff004726e3b0 tcp4 0/0/10 127.0.0.1.25
ffffff004726a760 tcp4 0/0/128 *.199
Принимаю решение тестово отключить вебку в mpd5.7, подключаюсь к консоли, делаю set web disable\ set web close, из-за чего теряю управление из локальной консоли, а в топе вижу статус mpd как umtxn. В этот момент в дмесг валится
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (160 occurrences)
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (1061 occurrences)
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (696 occurrences)
После чего возникает проблема с подключением как новых клиентов, так и работы текущих. убиваю процесс мпд и стартую новый. Смотрю netstat -LAan
Proto Listen Local Address
fffff800b3f02c00 tcp4 0/0/1024 ip.5006
Через консоль выключаю и включаю вебку снова - демон себя ведет нормально, но теперь подключений-то к нему
не много. После старта вебки снова 1024 очереди.
драйвера em пропатчены для увеличения кол-ва интераптов, добавлена поддержка шифрования\компрессии майкрософта,
наложен патч для решения проблемы переупорядочивания пакетов http://dadv.livejournal.com/198850.html
Сетевые igb и em, 4гб памяти\4ядра настольного амд процессора.
mpd:
startup:
set netflow peer ip 2000
set netflow timeouts 1 1
set user admin pass admin
set console self 127.0.0.1 5005
set console open
set web self ip 5006
set web enable auth
set web open
set radsrv peer ip pass
set radsrv self ip 1700
set radsrv open
load /usr/local/etc/mpd5/filter.conf filter
default:
load pptp_server
load l2tp_server
load pppoe_server
pptp_server:
set ippool add pool1 172.16.0.1 172.16.15.254
create bundle template B
set iface idle 0
set iface disable proxy-arp
set iface enable netflow-in netflow-out
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/script_up.sh
set iface down-script /usr/local/etc/mpd5/script_down.sh
set ipcp yes vjcomp
set ipcp ranges ip/32 ippool pool1
set ipcp dns ip ip
set bundle enable encryption
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
create link template L pptp
set link action bundle B
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap eap
set link enable chap
load radius
set link keep-alive 10 60
set link mtu 1460
set pptp self ip
set link enable incoming
set link enable peer-as-calling
l2tp_server:
set ippool add pool2 172.16.16.1 172.16.30.254
create bundle template B1
set iface idle 0
set iface disable proxy-arp
set iface enable netflow-in netflow-out
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/script_up.sh
set iface down-script /usr/local/etc/mpd5/script_down.sh
set ipcp yes vjcomp
set ipcp ranges ip/32 ippool pool2
set ipcp dns ip ip
set bundle enable compression
set bundle enable encryption
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
create link template L1 l2tp
set link action bundle B1
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap
set link enable chap
load radius
set link keep-alive 10 60
set link mtu 1460
set l2tp self ip
set link enable incoming
set link enable peer-as-calling
pppoe_server:
set ippool add pool3 172.16.31.1 172.16.45.254
create bundle template B2
set iface idle 0
set iface disable proxy-arp
set iface enable netflow-in netflow-out
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/script_up.sh
set iface down-script /usr/local/etc/mpd5/script_down.sh
set ipcp yes vjcomp
set ipcp ranges ip/32 ippool pool3
set ipcp dns ip
set bundle enable encryption
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
set bundle no crypt-reqd
create link template L2 pppoe
set link action bundle B2
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap eap
set link enable chap chap-msv1 chap-msv2 chap-md5
load radius
set link keep-alive 10 60
set pppoe service "*"
create link template L3 pppoe
set pppoe iface vlan2
set link enable incoming
set link enable peer-as-calling
create link template L4 pppoe
set pppoe iface vlan8
set link enable incoming
set link enable peer-as-calling
radius:
set radius server ip pass 1812 1813
set radius retries 5
set radius timeout 5
set radius me ip
set auth acct-update 120
set auth enable radius-auth
set auth enable radius-acct
set radius enable message-authentic
В принципе, по сравнению с 8.4-stable\5.6mpd здесь новое - это патч для решения проблемы переупорядочивания пакетов и 3 сервера на одном демоне.
Что посоветуете? Уж удивляет меня 1024 очереди на мпд в freebsd10.
Last edit: Y.S. 2014-09-15
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
1024 - это размер очереди
Возможные варианты проблемы - на поднятие/опускание интерфейса происходят какие-то действия (скрипты, devd, snmpd)
Что за странный патч для em "для увеличения кол-ва интераптов". Обычно пытаются уменьшить их.
Возможно ли вынести pppoe сервер на другую машину?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
devd... devd_enable="NO". Кажется, этого достаточно для devd. snmpd по трапам себя никак не ведет. Скрипты - исключительно up\down на прописывание маршрутов (мпдшные).
Странный\не странный, но при большом трафике получалась ситуация, что ресурсы процессора еще есть, а аномалии уже наблюдаются. Подробно писал Евгений Гросбеин здесь: http://dadv.livejournal.com/139170.html Поллинг не использую.
PPPoE еще не используется, вынести из конфига его вполне возможно. Хотелось бы понять почему в этом может быть необходимость.
В чем заключалась\заключается частично пофикшеная проблема? В каком размере она пофикшена?
Как раз сейчас 2 недели машина крутится увеличенным soamaxconn до 2048. 1 раз сообщение о оверлоу было в логах. Судя по всему kern.ipc.soacceptqueue и есть kern.ipc.somaxconn : http://lists.freebsd.org/pipermail/svn-src-head/2012-October/041326.html
Т.е., размером очереди можно было управлять и в более ранних версиях freebsd. Я не понимаю Вашу фразу "Размером очереди теперь можно управлять".
Из каких вообще соображений выбирать значение kern.ipc.soacceptqueue ?
P.S. Эти 2 недели мпд крутится на машине, собранной с WITHOUT_UTMPX=YES, указанной в src.conf и выкинутом ipv6 из конфига ядра. Указывая в src.conf WITHOUT_INET6, 6-ки в системе как и положено -нет, но...Замечено ранее, что с включенной поддержкой ipv6 наблюдаются паники и ребуты. Так вот с WITHOUT_INET6 все так же наблюдал ребуты, выкинув из конфига ядра - все ок.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
По тюнингу сетевух и netgraph смотрите последние минуты моего доклада: https://www.youtube.com/watch?v=NuEb6IApTVM
Собственно говоря, весь тюнинг заключается в том, чтобы не мешать процессу netgraph работать.
До фикса очередь входящих соединений в mpd была фиксирована, и равнялась 2, Что видно из первого поста (fffff8004856d800 tcp4 0/0/2 ip.1723). Теперь ей можно управлять через kern.ipc.soacceptqueue
snmpd желательно тоже отключить, так как он выполняет какие-то телодвижения при создании/удалении интерфейсов
В идеале, на машине с mpd вообще ничего, кроме mpd и роутинга не должно быть.
Весь трафик не должен выходить из netgraph. PF, IPFW, ALTQ, DUMMYNET и т.п. очень желательно вынести на другую машину.
Mpd лезет в netgraph только для того, чтобы получить статистику, соответственно переключается контекст. Чем меньше mpd туда лезет, тем меньше нагрузка на CPU.
соответсвенно, нужно пересмотреть следующие значения:
set link keep-alive 10 60 - проверяет, изменилось ли количество пакетов на интерфейсе
set auth acct-update 120 - собирает статистику
На нагруженных серверах у меня стоит
- set link keep-alive 60 120
- set auth acct-update 800
Посмотреть количество переключений контекста можно по "top -m io"
Всякие скрипты set iface up-script /usr/local/etc/mpd5/script_up.sh и
set iface down-script /usr/local/etc/mpd5/script_down.sh приостанавливают mpd, потому как mpd ждет их завершения. Желательно вообще от них избавиться, или попытаться уменьшить время выполнения скриптов.
Кроме того, в последней CVS версии добавлена возможность выкидывать ng_tee из цепочки нод после поднятия линка, что уменьшает один вызов mtx_lock() при прохождении каждого пакета по цепочке.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Видео посмотрел, спасибо. По тюнингу нетграфа - понятно и используется, по разбросу по ядрам.. Не об этом топик, наверное, но мысль выноса на отдельные ядра ng_queue и интерапты наверное имеет место быть на 8-и ядерной и более системе. 2 машины (8.4-stable 10.1-beta) http://clip2net.com/s/j6LQuf с em и igb в работе (2 головы в работе) из коробки. Даже с em из коробки неплохо вплане балансировки загрузки ядер. Или я что-то неправильно трактую из своих top-ов? Заранее благодарен за развернутый коментарий, т.к. на первую машину хотелось бы поставить еще один процессор и перебросить трафик на igb, увеличив общую нагрузку на машину.
3.Сюда еще квагу или опенбгпд добавить нужно, на самом деле. pf вынесу чуть позже, сейчас это не позволительно (требуется пара фильтр-правил). car не вынести.. Вроде бы всё здесь, трафик "в нетрафе". Кстати, судя по ngctl list, у меня используются car bpf tcpmss ppp iface ksocket socket pptpgre tee l2tp ether netflow. Нетграф в ядре целиком. Стоит ли выкидывать всякие ASYNC DEFLATE VJC TTY BRIDGE PRED1 NAT MPPC.. ?
set link keep-alive 10 60 \set auth acct-update 120 \спасибо, обращу внимание.
на 8-ке, только пптп
PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
22939 root 313 278 0 0 0 0 0.00% mpd5
1180 root 0 0 0 0 0 0 0.00% snmpd
551 root 199 44 0 0 0 0 0.00% samplicate
60921 root 49 12 0 0 0 0 0.00% syslogd
на 10-ке, 3 демона
PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
631 root 270 2416 0 0 0 0 0.00% mpd5
637 root 3 815 0 0 0 0 0.00% snmpd
401 root 228 101 0 0 0 0 0.00% samplicate
up\down скрипты.. да там только прописывание маршрута при поднятии определенного туннеля. Всё. Нечему там оптимизироваться во времени выполнения, разве что выкинуть down скрипт как таковой, ну исчез адрес шлюза для маршрута, ну и всё на этом.
Last edit: Y.S. 2014-10-17
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Добре. Собственно, танцы с бубном были с выкидыванием в6 из системы, девд отключения и прочие мелочи. Кажется, пока не была система собрана без поддержки в6, эти непонятные проблемы с разгребанием очереди (по-делитански делаю такой вывод) я встречал очень и очень часто на 10-ке. После выкидывания в6 все-таки проблемы есть, словил эту же ситуацию сегодня. Ранее питание падало, поэтому не мешал этому "живому" тесту. Проблема не ушла, она все так же есть.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Дилетантские мысли-предположения ситуации:
ранее, в 8.4, переполнение очереди вероятно так же было, но об этом я не знал, а к проблемам с mpd это не приводило; сейчас что-то изменилось в системе и проблемы с разгребанием очереди приводят к проблемам с mpd.
Если я прав, то есть 2 стороны медали
1. Тюнинг и запас производительности до ситуации, когда переполнения очередей не будет. Наверное, утопия, ведь ситуаций переполнения при всяких там ддосах может быть много
2. Работоспособность при переполнениях. Ранее, выходит, были эти переполнения и мпд жил.
Я несу бред или прав?
P.S.
Посмотреть кто такие
Feb 1 00:35:11 nas02 kernel: sonewconn: pcb 0xfffff8004826f930: Listen queue overflow: 4 already in queue awaiting acceptance (34 occurrences)
Feb 9 19:51:35 nas02 kernel: sonewconn: pcb 0xfffff80091657188: Listen queue overflow: 4 already in queue awaiting acceptance (29 occurrences)
не получилось, т.к. система крайне не отзывчива была и меньшим риском было отправить ее в рестарт, чем потерять удаленный доступ :(
Но: зачем увеличение очереди ip.5006 ?
Мы можем бесконечно выносить всё с такого браса, но оставшись на нем только роутинг и терминация туннелей.. он будет почти бесполезен. Нетфлов, элементы маршрутизации для определенных ng при подъеме таковых (в up\down скриптах оно), шейпинг по подсетям из фильтра и цоа - тот разумный минимум, который от такой коробки нужен. Работать с этим без мониторинга не возможно, поэтому снмп что-то о системе и ее состоянии явно должен рассказать.
Простите за эмоции.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In new versions of Freebsd you can do not set kern.ipc.maxsockets < kern.maxfiles, then for example configure:
kern.maxfiles = 256000
kern.maxfilesperproc = 256000
And then will let you increase the number of sockets:
kern.ipc.maxsockets = 256000
The kern.ipc.maxsockets today is calculated based on your hardware.
Hope this helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
А когда в портах будет пофикшеная версия?
"sonewconn: pcb 0xfffff801d74c8ab8: Listen queue overflow" уже достаёт конкретно, причём только на 5.7, на 5.6 жужжит без проблем..
Может пока есть резон откатить до 5.6?
Last edit: alkov 2015-04-22
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Проблема проявляется на любых версиях FreeBSD при больших нагрузках
У меня не подвердилось. Предполагаю, что главный виновник здесь snmpd...
История такова:
1. "до того как" на машине c FreeBSD 9.0 работал и не жужжал mpd5.6
2. в какой-то момент на машине навернулся HDD, соотв. пришлось ставить всё с нуля..
И вот тогда-то, как говориться, дёрнул чёрт поставить FreeBSD 10.1-RC3 и подчеркну - всю ту же mpd5.6.
Первой ласточкой стали "рваные" графики в Cacti (мониторю трафик и ппс).
Причём проблем, как таковых замечено не было.
Далее в какой-то не совсем определённый момент (чаще всего тогда, когда траф переваливает за 500Мбит) происходит ступор mpd.
Последний отказывается общаться с радиусом и соотв. принимать запросы на поднятие новой сессии. При этом "старые" сессии исправно работают.
В логе радиуса ничего, кроме того, что нет "общения" с NAS-ом. Т.е. выглядит как бы останов последнего.
Если в этот момент попытаться сделать mp5 restart, то процесс останова ничем не заканчивается, после kill -9 pid mpd5 в системе остаётся куча ng интерфейсов..
Приходится делать ребут всей машины.
3. Недавно установил mpd5.7 (собрал из CVS).
"Дыры" на графиках Cacti не исчезли, но и проблема пока не появлялась.
Ощущение, что она вот-вот объявится не исчезло.
Вообщем, готовлюсь откатиться на FreeBSD 9.1, где всё работает годами.
Например, есть NAS на FreeBSD 9.0-RELEASE и mpd 5.6, держит около 900 сессий и 650 Мбит траф. "Дыр" на его графиках не наблюдается.
... Убежал на 9-ку ранее, все-таки. Порт обновился и в 9-ке и в 10-ке? Возможно, апгрейдну мпд, т.к. сейчас в проявились проблемы с отъеданием процессора ng_queue с повышением пинга и увеличением значений dev.igb.0.queue0.interrupt_rate
sonewconn: pcb 0xfffffe001a62a310: Listen queue overflow иногда проскакивает, но без явных проблем. Никакого намеда там нет. snmp сейчас тоже нет.
alkov - Можете поделиться своими тюнингами конфигами и мыслями стабильной нагруженной конфигуации?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Сейчас FreeBSD 10.1-RC3 amd64, mpd Version 5.8a, uptime машины - 276 days.
Правда собственно mpd ребутаю раз в месяц (каждое 1-е число).
Макс. зафиксировано 925 ppp сессий и 750 Mbit/s
Что и как тюнил, увы, уже не помню.. Вроде, ничего особенного.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Добрый день.
Есть себе машина на freebsd 8.4 stable\mpd 5.6, работает около 240 дней, все ок.
Наработки по тюнингу были использвоны в новой машине на freebsd 10\mpd 5.7. Пересобрал мир\ядро,
проработала машина недели 2 и климануло mpd5. r26* билд freebsd10-stable там был.
Климануло точно известно с сообщением в дмесг
kernel: sonewconn: pcb 0xfffff8005927*: Listen queue overflow: 4 already in queue awaiting acceptance (500 occurrences) Демон климануло так, что рестартился он долго. После рестарта наблюдал не совсем объяснимые потери
пакетов через туннель, поэтому решил перезагрузить машину и заодно пересобрать ядро и мир, да увеличить kern.ipc.somaxconn до 2048 не особенно понимая почему лимит мог быть исчерпан.
Через несколько дней полета такой машины
uname -a
FreeBSD nas02.st.su 10.1-PRERELEASE FreeBSD 10.1-PRERELEASE #0 r271303M: Tue Sep 9 11:52:45 FET 2014 root@nas02.st.su:/usr/obj/usr/src/sys/sin-09092014 amd64
root@nas02:~ # mpd5 -v
Version 5.7 (root@10amd64-default-job-22 19:26 12-Jun-2014)
смотрю netstat -LAan
netstat -LAan
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb Proto Listen Local Address
fffff800b3f02c00 tcp4 0/0/1024 ip.5006
fffff8004856d800 tcp4 0/0/2 ip.1723
fffff800b3fe6c00 tcp4 0/0/2 127.0.0.1.5005
fffff800573ee400 tcp4 0/0/10 127.0.0.1.25
fffff800572d3400 tcp4 0/0/128 ip.2215
fffff8005735a400 tcp4 0/0/128 *.199
В мпд включены как pptp, так l2tp, так и pppoe демоны и вебка. 1024 активных очереди? на 5006 порту как раз вебка мпд.
Смотрю на машине с 8.4bsd\5.6mpd
netstat -LAan
Current listen queue sizes (qlen/incqlen/maxqlen)
Tcpcb Proto Listen Local Address
ffffff00d5a45760 tcp4 0/0/128 ip.2215
ffffff00c4bd4b10 tcp4 0/0/2 ip.1723
ffffff00c6015000 tcp4 0/0/128 ip.5006
ffffff006c637760 tcp4 0/0/2 127.0.0.1.5005
ffffff004726e3b0 tcp4 0/0/10 127.0.0.1.25
ffffff004726a760 tcp4 0/0/128 *.199
Принимаю решение тестово отключить вебку в mpd5.7, подключаюсь к консоли, делаю set web disable\ set web close, из-за чего теряю управление из локальной консоли, а в топе вижу статус mpd как umtxn. В этот момент в дмесг валится
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (160 occurrences)
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (1061 occurrences)
sonewconn: pcb 0xfffff800572d0930: Listen queue overflow: 4 already in queue awaiting acceptance (696 occurrences)
После чего возникает проблема с подключением как новых клиентов, так и работы текущих. убиваю процесс мпд и стартую новый. Смотрю netstat -LAan
Proto Listen Local Address
fffff800b3f02c00 tcp4 0/0/1024 ip.5006
Через консоль выключаю и включаю вебку снова - демон себя ведет нормально, но теперь подключений-то к нему
не много. После старта вебки снова 1024 очереди.
loader:
net.graph.maxdata=65536
net.graph.maxalloc=65536
hw.em.rxd=4096
hw.em.txd=4096
hw.igb.rxd=4096
hw.igb.txd=4096
hw.igb.rx_process_limit=4096
hw.igb.max_interrupt_rate=64000
hw.igb.lro=0
net.route.netisr_maxqlen=4096
net.isr.defaultqlimit=4096
net.link.ifqmaxlen=10240
autoboot_delay="1"
kern.maxfiles = "25000"
net.isr.direct=1
net.isr.direct_force=1
net.isr.bindthreads=1
kern.ipc.nmbclusters=400000
sysctl
dev.em.0.rx_int_delay=200
dev.em.0.tx_int_delay=200
dev.em.0.rx_abs_int_delay=4000
dev.em.0.tx_abs_int_delay=4000
dev.em.0.rx_processing_limit=4096
dev.em.0.max_interrupt_rate=32000
dev.em.1.rx_int_delay=200
dev.em.1.tx_int_delay=200
dev.em.1.rx_abs_int_delay=4000
dev.em.1.tx_abs_int_delay=4000
dev.em.1.rx_processing_limit=4096
dev.em.1.max_interrupt_rate=32000
dev.igb.0.rx_processing_limit=4096
dev.igb.1.rx_processing_limit=4096
dev.igb.0.fc=0
dev.igb.1.fc=0
net.inet.ip.fastforwarding=1
net.inet.tcp.blackhole=2
net.inet.udp.blackhole=1
net.inet.icmp.icmplim_output=0
net.inet.icmp.icmplim=100
net.inet.tcp.drop_synfin=1
net.inet.ip.ttl=128
net.route.netisr_maxqlen=4096
net.inet.ip.redirect=0
net.inet.ip.intr_queue_maxlen=10240
net.graph.maxdgram=8388608
net.graph.recvspace=8388608
kern.random.sys.harvest.ethernet=0
kern.random.sys.harvest.point_to_point=0
kern.random.sys.harvest.interrupt=0
net.inet.raw.maxdgram=16384
net.inet.raw.recvspace=16384
net.graph.mppe.max_rekey=-1000
kern.ipc.somaxconn=2048
net.inet.icmp.drop_redirect=1
net.inet.icmp.log_redirect=1
net.inet.ip.check_interface=1
rc.conf
sshd_enable="YES"
ntpd_enable="YES"
dumpdev="AUTO"
dumpdir="/var/crash"
savecore_flags="-v"
gateway_enable="YES"
defaultrouter="ip"
ifconfig_igb0="inet ip netmask 255.255.255.224 -rxcsum -txcsum -lro -tso"
ifconfig_igb1="inet ip netmask 255.255.255.248 -rxcsum -txcsum -lro -tso"
vlans_em0="vlan8 vlan2"
create_args_vlan8="vlan 8"
create_args_vlan2="vlan 2"
mpd_enable="YES"
snmpd_enable="YES"
snmpd_conffile="/usr/local/share/snmp/snmpd.conf"
pf_enable="YES"
pf_rules="/etc/pf.conf"
pflog_enable="NO"
static_routes="1 2 3 4 5 6 7 8"
route_1= ....
/usr/local/bin/samplicate -f -p 2000 -s ip -S ip/9995 ip/9996
devd_enable="NO"
sendmail_enable="NO"
ядро:
отключены вайфай карты, звуковые, ипв6, добавлен нетграф и чуть-чуть еще:
options NETGRAPH
options NETGRAPH_ASYNC
options NETGRAPH_BPF
options NETGRAPH_BRIDGE
options NETGRAPH_CAR
options NETGRAPH_DEFLATE
options NETGRAPH_ETHER
options NETGRAPH_IFACE
options NETGRAPH_IPFW
options NETGRAPH_KSOCKET
options NETGRAPH_L2TP
options NETGRAPH_MPPC_COMPRESSION
options NETGRAPH_MPPC_ENCRYPTION
options NETGRAPH_NETFLOW
options NETGRAPH_NAT
options NETGRAPH_PPP
options NETGRAPH_PPPOE
options NETGRAPH_PPTPGRE
options NETGRAPH_PRED1
options NETGRAPH_SOCKET
options NETGRAPH_TCPMSS
options NETGRAPH_TEE
options NETGRAPH_TTY
options NETGRAPH_VJC
options PANIC_REBOOT_WAIT_TIME=16
device coretemp
options ROUTETABLES=3
options OFED
options SDP
device ipoib
options IPOIB_CM
device mlxen
device mlx4ib
драйвера em пропатчены для увеличения кол-ва интераптов, добавлена поддержка шифрования\компрессии майкрософта,
наложен патч для решения проблемы переупорядочивания пакетов http://dadv.livejournal.com/198850.html
Сетевые igb и em, 4гб памяти\4ядра настольного амд процессора.
mpd:
startup:
set netflow peer ip 2000
set netflow timeouts 1 1
set user admin pass admin
set console self 127.0.0.1 5005
set console open
set web self ip 5006
set web enable auth
set web open
set radsrv peer ip pass
set radsrv self ip 1700
set radsrv open
load /usr/local/etc/mpd5/filter.conf filter
default:
load pptp_server
load l2tp_server
load pppoe_server
pptp_server:
set ippool add pool1 172.16.0.1 172.16.15.254
create bundle template B
set iface idle 0
set iface disable proxy-arp
set iface enable netflow-in netflow-out
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/script_up.sh
set iface down-script /usr/local/etc/mpd5/script_down.sh
set ipcp yes vjcomp
set ipcp ranges ip/32 ippool pool1
set ipcp dns ip ip
set bundle enable encryption
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set link enable multilink
set link yes acfcomp protocomp
set link no pap chap eap
set link enable chap
load radius
set link keep-alive 10 60
set link mtu 1460
set pptp self ip
set link enable incoming
set link enable peer-as-calling
l2tp_server:
set ippool add pool2 172.16.16.1 172.16.30.254
create bundle template B1
set iface idle 0
set iface disable proxy-arp
set iface enable netflow-in netflow-out
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/script_up.sh
set iface down-script /usr/local/etc/mpd5/script_down.sh
set ipcp yes vjcomp
set ipcp ranges ip/32 ippool pool2
set ipcp dns ip ip
set bundle enable compression
set bundle enable encryption
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set mppc yes stateless
pppoe_server:
set ippool add pool3 172.16.31.1 172.16.45.254
create bundle template B2
set iface idle 0
set iface disable proxy-arp
set iface enable netflow-in netflow-out
set iface enable tcpmssfix
set iface up-script /usr/local/etc/mpd5/script_up.sh
set iface down-script /usr/local/etc/mpd5/script_down.sh
set ipcp yes vjcomp
set ipcp ranges ip/32 ippool pool3
set ipcp dns ip
set bundle enable encryption
set bundle enable compression
set ccp yes mppc
set mppc yes e40
set mppc yes e128
set link enable incoming
set link enable peer-as-calling
create link template L4 pppoe
set pppoe iface vlan8
set link enable incoming
set link enable peer-as-calling
radius:
set radius server ip pass 1812 1813
set radius retries 5
set radius timeout 5
set radius me ip
set auth acct-update 120
set auth enable radius-auth
set auth enable radius-acct
set radius enable message-authentic
В принципе, по сравнению с 8.4-stable\5.6mpd здесь новое - это патч для решения проблемы переупорядочивания пакетов и 3 сервера на одном демоне.
Что посоветуете? Уж удивляет меня 1024 очереди на мпд в freebsd10.
Last edit: Y.S. 2014-09-15
1024 - это размер очереди
Возможные варианты проблемы - на поднятие/опускание интерфейса происходят какие-то действия (скрипты, devd, snmpd)
Что за странный патч для em "для увеличения кол-ва интераптов". Обычно пытаются уменьшить их.
Возможно ли вынести pppoe сервер на другую машину?
Проблема частично пофикшена в CVS
Размером очереди теперь можно управлять с помощью kern.ipc.soacceptqueue
devd... devd_enable="NO". Кажется, этого достаточно для devd. snmpd по трапам себя никак не ведет. Скрипты - исключительно up\down на прописывание маршрутов (мпдшные).
Странный\не странный, но при большом трафике получалась ситуация, что ресурсы процессора еще есть, а аномалии уже наблюдаются. Подробно писал Евгений Гросбеин здесь: http://dadv.livejournal.com/139170.html Поллинг не использую.
PPPoE еще не используется, вынести из конфига его вполне возможно. Хотелось бы понять почему в этом может быть необходимость.
В чем заключалась\заключается частично пофикшеная проблема? В каком размере она пофикшена?
Как раз сейчас 2 недели машина крутится увеличенным soamaxconn до 2048. 1 раз сообщение о оверлоу было в логах. Судя по всему kern.ipc.soacceptqueue и есть kern.ipc.somaxconn : http://lists.freebsd.org/pipermail/svn-src-head/2012-October/041326.html
Т.е., размером очереди можно было управлять и в более ранних версиях freebsd. Я не понимаю Вашу фразу "Размером очереди теперь можно управлять".
Из каких вообще соображений выбирать значение kern.ipc.soacceptqueue ?
P.S. Эти 2 недели мпд крутится на машине, собранной с WITHOUT_UTMPX=YES, указанной в src.conf и выкинутом ipv6 из конфига ядра. Указывая в src.conf WITHOUT_INET6, 6-ки в системе как и положено -нет, но...Замечено ранее, что с включенной поддержкой ipv6 наблюдаются паники и ребуты. Так вот с WITHOUT_INET6 все так же наблюдал ребуты, выкинув из конфига ядра - все ок.
Собственно говоря, весь тюнинг заключается в том, чтобы не мешать процессу netgraph работать.
В идеале, на машине с mpd вообще ничего, кроме mpd и роутинга не должно быть.
Весь трафик не должен выходить из netgraph. PF, IPFW, ALTQ, DUMMYNET и т.п. очень желательно вынести на другую машину.
Mpd лезет в netgraph только для того, чтобы получить статистику, соответственно переключается контекст. Чем меньше mpd туда лезет, тем меньше нагрузка на CPU.
соответсвенно, нужно пересмотреть следующие значения:
На нагруженных серверах у меня стоит
- set link keep-alive 60 120
- set auth acct-update 800
Посмотреть количество переключений контекста можно по "top -m io"
Всякие скрипты set iface up-script /usr/local/etc/mpd5/script_up.sh и
set iface down-script /usr/local/etc/mpd5/script_down.sh приостанавливают mpd, потому как mpd ждет их завершения. Желательно вообще от них избавиться, или попытаться уменьшить время выполнения скриптов.
Кроме того, в последней CVS версии добавлена возможность выкидывать ng_tee из цепочки нод после поднятия линка, что уменьшает один вызов mtx_lock() при прохождении каждого пакета по цепочке.
3.Сюда еще квагу или опенбгпд добавить нужно, на самом деле. pf вынесу чуть позже, сейчас это не позволительно (требуется пара фильтр-правил). car не вынести.. Вроде бы всё здесь, трафик "в нетрафе". Кстати, судя по ngctl list, у меня используются car bpf tcpmss ppp iface ksocket socket pptpgre tee l2tp ether netflow. Нетграф в ядре целиком. Стоит ли выкидывать всякие ASYNC DEFLATE VJC TTY BRIDGE PRED1 NAT MPPC.. ?
set link keep-alive 10 60 \set auth acct-update 120 \спасибо, обращу внимание.
на 8-ке, только пптп
PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
22939 root 313 278 0 0 0 0 0.00% mpd5
1180 root 0 0 0 0 0 0 0.00% snmpd
551 root 199 44 0 0 0 0 0.00% samplicate
60921 root 49 12 0 0 0 0 0.00% syslogd
на 10-ке, 3 демона
PID USERNAME VCSW IVCSW READ WRITE FAULT TOTAL PERCENT COMMAND
631 root 270 2416 0 0 0 0 0.00% mpd5
637 root 3 815 0 0 0 0 0.00% snmpd
401 root 228 101 0 0 0 0 0.00% samplicate
up\down скрипты.. да там только прописывание маршрута при поднятии определенного туннеля. Всё. Нечему там оптимизироваться во времени выполнения, разве что выкинуть down скрипт как таковой, ну исчез адрес шлюза для маршрута, ну и всё на этом.
Last edit: Y.S. 2014-10-17
Какие-то изменения есть?
Вообще да, работает. mpd точно не обновлял, после чего именно - позже напишу.
С нетерпением жду
Добре. Собственно, танцы с бубном были с выкидыванием в6 из системы, девд отключения и прочие мелочи. Кажется, пока не была система собрана без поддержки в6, эти непонятные проблемы с разгребанием очереди (по-делитански делаю такой вывод) я встречал очень и очень часто на 10-ке. После выкидывания в6 все-таки проблемы есть, словил эту же ситуацию сегодня. Ранее питание падало, поэтому не мешал этому "живому" тесту. Проблема не ушла, она все так же есть.
Дилетантские мысли-предположения ситуации:
ранее, в 8.4, переполнение очереди вероятно так же было, но об этом я не знал, а к проблемам с mpd это не приводило; сейчас что-то изменилось в системе и проблемы с разгребанием очереди приводят к проблемам с mpd.
Если я прав, то есть 2 стороны медали
1. Тюнинг и запас производительности до ситуации, когда переполнения очередей не будет. Наверное, утопия, ведь ситуаций переполнения при всяких там ддосах может быть много
2. Работоспособность при переполнениях. Ранее, выходит, были эти переполнения и мпд жил.
Я несу бред или прав?
P.S.
Посмотреть кто такие
Feb 1 00:35:11 nas02 kernel: sonewconn: pcb 0xfffff8004826f930: Listen queue overflow: 4 already in queue awaiting acceptance (34 occurrences)
Feb 9 19:51:35 nas02 kernel: sonewconn: pcb 0xfffff80091657188: Listen queue overflow: 4 already in queue awaiting acceptance (29 occurrences)
не получилось, т.к. система крайне не отзывчива была и меньшим риском было отправить ее в рестарт, чем потерять удаленный доступ :(
Но: зачем увеличение очереди ip.5006 ?
Мы можем бесконечно выносить всё с такого браса, но оставшись на нем только роутинг и терминация туннелей.. он будет почти бесполезен. Нетфлов, элементы маршрутизации для определенных ng при подъеме таковых (в up\down скриптах оно), шейпинг по подсетям из фильтра и цоа - тот разумный минимум, который от такой коробки нужен. Работать с этим без мониторинга не возможно, поэтому снмп что-то о системе и ее состоянии явно должен рассказать.
Простите за эмоции.
В CVS версии размер очереди уведичен с 4-х, до переменной, выставляемой kern.ipc.somaxconn. По умолчанию - 128
In new versions of Freebsd you can do not set kern.ipc.maxsockets < kern.maxfiles, then for example configure:
kern.maxfiles = 256000
kern.maxfilesperproc = 256000
And then will let you increase the number of sockets:
kern.ipc.maxsockets = 256000
The kern.ipc.maxsockets today is calculated based on your hardware.
Hope this helps.
freebsd9.3 r278845M
$FreeBSD: head/net/mpd5/Makefile 375100 2014-12-20 19:23:19Z bapt $
MAINTAINER= mav@FreeBSD.org
mpd5 -v
Version 5.7 (root@93amd64-default-job-17 22:10 9-Jan-2015)
Я правильно понимаю, что эти изменения в порте произведены?
нет. в CVS
ок.
1. проблеме подвластна мпд и на 9-ке?
2. возможно где-то уже пробегал правильный вариант сборки мпд из cvs ?
А когда в портах будет пофикшеная версия?
"sonewconn: pcb 0xfffff801d74c8ab8: Listen queue overflow" уже достаёт конкретно, причём только на 5.7, на 5.6 жужжит без проблем..
Может пока есть резон откатить до 5.6?
Last edit: alkov 2015-04-22
У меня не подвердилось. Предполагаю, что главный виновник здесь snmpd...
История такова:
1. "до того как" на машине c FreeBSD 9.0 работал и не жужжал mpd5.6
2. в какой-то момент на машине навернулся HDD, соотв. пришлось ставить всё с нуля..
И вот тогда-то, как говориться, дёрнул чёрт поставить FreeBSD 10.1-RC3 и подчеркну - всю ту же mpd5.6.
Первой ласточкой стали "рваные" графики в Cacti (мониторю трафик и ппс).
Причём проблем, как таковых замечено не было.
Далее в какой-то не совсем определённый момент (чаще всего тогда, когда траф переваливает за 500Мбит) происходит ступор mpd.
Последний отказывается общаться с радиусом и соотв. принимать запросы на поднятие новой сессии. При этом "старые" сессии исправно работают.
В логе радиуса ничего, кроме того, что нет "общения" с NAS-ом. Т.е. выглядит как бы останов последнего.
Если в этот момент попытаться сделать mp5 restart, то процесс останова ничем не заканчивается, после kill -9 pid mpd5 в системе остаётся куча ng интерфейсов..
Приходится делать ребут всей машины.
3. Недавно установил mpd5.7 (собрал из CVS).
"Дыры" на графиках Cacti не исчезли, но и проблема пока не появлялась.
Ощущение, что она вот-вот объявится не исчезло.
Вообщем, готовлюсь откатиться на FreeBSD 9.1, где всё работает годами.
Например, есть NAS на FreeBSD 9.0-RELEASE и mpd 5.6, держит около 900 сессий и 650 Мбит траф. "Дыр" на его графиках не наблюдается.
Last edit: alkov 2015-08-30
до 10.2 сделаю порт
абсолютно аналогичная проблема была решена убиранием намеда на соседнюю машину
... Убежал на 9-ку ранее, все-таки. Порт обновился и в 9-ке и в 10-ке? Возможно, апгрейдну мпд, т.к. сейчас в проявились проблемы с отъеданием процессора ng_queue с повышением пинга и увеличением значений dev.igb.0.queue0.interrupt_rate
sonewconn: pcb 0xfffffe001a62a310: Listen queue overflow иногда проскакивает, но без явных проблем. Никакого намеда там нет. snmp сейчас тоже нет.
alkov - Можете поделиться своими тюнингами конфигами и мыслями стабильной нагруженной конфигуации?
увеличилось количество сессий и проблема появилась вновь
помогает только полная перезагрузка
[11:03] /root >sysctl -a | grep kern.ipc.soacceptqueue
kern.ipc.soacceptqueue: 16384
[11:04] /root >sysctl -a | grep pcb
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (396 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (2697 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (5867 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7064 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7474 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7489 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7265 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7379 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7404 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7389 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7264 occurrences)
<7>sonewconn: pcb 0xfffff8007b1eb7a8: Listen queue overflow: 4 already in queue awaiting acceptance (7401 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (243 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (1862 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (4864 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (6122 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (5992 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (5669 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (5998 occurrences)
<7>sonewconn: pcb 0xfffff801ae314498: Listen queue overflow: 4 already in queue awaiting acceptance (6025 occurrences)
<7>sonewconn: pcb 0xfffff800538de498: Listen queue overflow: 4 already in queue awaiting acceptance (1 occurrences)
net.inet.tcp.pcbcount: 322
net.inet.sctp.pcbhashsize: 256
Аналогичная проблема. 10.1-RC3. Щас думаю обновиться до 10.3
проблему удалось победить?
Сейчас FreeBSD 10.1-RC3 amd64, mpd Version 5.8a, uptime машины - 276 days.
Правда собственно mpd ребутаю раз в месяц (каждое 1-е число).
Макс. зафиксировано 925 ppp сессий и 750 Mbit/s
Что и как тюнил, увы, уже не помню.. Вроде, ничего особенного.