Страница 1 из 2
Использование альтернативного демона pptpd accel-pptpd
Добавлено: Ср дек 17, 2008 6:36 am
nsa
В общем пытался оптимизировать связку pptp+pppd+kernel и наткнулся на проект accel-pptp, по словам автора понял что это ядерный pptp, даже при нагрузке в 1200 коннектов загрузка процессор, память упала на 50 % также оптимизирована производительность с одного соединения удается получить до 7 ~ 8 МБ/сек. Хотя на странице проекта зафиксирована 11 МБ/сек.
Я пропатчил ядро и установил сабж, действительно производительность увеличилась при этом процессор отдыхал.
Если кому то интересно по тестируйте зверька, поделимся результатами!
Страница проекта
http://accel-pptp.sourceforge.net/
Добавлено: Ср дек 17, 2008 5:20 pm
NiTr0
Интересно, поставлю на тестовую машинку, потестирую... Т.к. с оригинальным pptpd у меня имеется некий странный геморрой по части производительности - чем больше аптайм, тем больше грузится проц, и 500 сессий с 110 мбит суммарного трафа практически полностью загружают атлон 5600+.
Сколько у вас клиентов это чудо тянуло, на какой машине, какой траф и какая загрузка проца была?
Добавлено: Чт дек 18, 2008 6:14 am
nsa
Я проверял косвенным методом, использовал обычный poptop v1.3.4 и accel-pptp.
Пробовал качать файлы:
так вот с обычного poptop сервера получил скорость до 24 Mbit/sec при этом загрузка процессора увеличилась на 11 процентов, при тех же самых условиях но с accel-pptp удалось разогнать до 50 Mbit/sec при этом загрузки практически небыло то что я увидел в task manager меня поразило процессоры практически отдыхали Использование процессорного времени данным процессом составило 0.0% и памяти 0.1%!
Данные проца
processor : 0
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 4
cpu MHz : 2791.329
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm
bogomips : 5587.50
processor : 1
vendor_id : GenuineIntel
cpu family : 15
model : 6
model name : Intel(R) Pentium(R) D CPU 2.80GHz
stepping : 4
cpu MHz : 2791.329
cache size : 2048 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 6
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe nx lm constant_tsc pni monitor ds_cpl est cid cx16 xtpr lahf_lm
bogomips : 5582.85
Пришел к выводу что использование обычного не ядерного poptop приводит к деградации сервиса при большом количестве активных пользователей также зависящее от ширины канала!
То есть как вы говорили
NiTr0 писал(а):Чем больше аптайм, тем больше грузится проц, и 500 сессий с 110 мбит суммарного трафа практически полностью загружают атлон 5600+.
Так вот при использовании обычного poptop с его userlevel обработкой ip_gre трафика мне кажется что если ваш канал будет увеличиваться то это приведет к деградации NAS Сервера какой бы мощный он не был.
Опять таки может я не прав но многие факты свидетельствуют об этом !
Вот к примеру один из них!
http://misc-heap.blogspot.com/2008/04/p ... linux.html
Добавлено: Вс дек 21, 2008 8:09 pm
NiTr0
Поставил на резервную машину (атлон 3000+), с некоторыми шаманствами (инсталлка под 64бит ОС криво работает) - вроде как работает... завтра основную массу клиентов перекину на ту машинку, посмотрю на загрузку (500 чел грузят атлон 5600+ на 85-90%, хотя основная загрузка идет на software interrupts...)
Добавлено: Пн дек 22, 2008 5:45 pm
NiTr0
Итак, на сервере 426 пользователей, траффик - порядка 80 мбит суммарный, загрузка проца - чуть больше 18%... Хотя кое-кто из людей жаловался на ошибки соединения - но их источник пока не выяснен (возможно, глюки локалки).
При 463 юзерах - загрузка проца 22%, траффик - около тех же 80 мбит...
Добавлено: Вс янв 04, 2009 8:26 am
Ali
NiTr0 писал(а):Итак, на сервере 426 пользователей, траффик - порядка 80 мбит суммарный, загрузка проца - чуть больше 18%... Хотя кое-кто из людей жаловался на ошибки соединения - но их источник пока не выяснен (возможно, глюки локалки).
При 463 юзерах - загрузка проца 22%, траффик - около тех же 80 мбит...
ребята а етот впн понимает мcчап-v2 и mppe ?
знаю что мппе зло но на данный момент многие клиенты на нем сидят, и всех обзвонить и переделать настройки почти нереально (
Добавлено: Вс янв 04, 2009 7:35 pm
NiTr0
Поднимите на какой-то машине попробуйте
ИМХО - должен, т.к. это - тот же поптоп, только с вынесенным в модуль ядра кодом работы с туннелями.
P.S. Аптайм уже 2 недели - проблем нет.
Добавлено: Ср янв 07, 2009 10:03 am
Ali
NiTr0 писал(а):
P.S. Аптайм уже 2 недели - проблем нет.
c MPPE пашет, все в норме, разгрузка проца колоссальная, была загрузка 10-20% теперь упала до 1-2%, но есть какие-то странности отваливаются некоторые юзеры вот что обнаружил в логах
MGR: dropped slow initial connection
MGR: dropped small initial connection
пинги в инет уходят пачками, 30 пингов прошло потом затык итд...
не пойму че такое.... пробовал и с мппе и без, не в нем дело,
поделитесь у кого какой конфиг что ли
причем когда мало впн-соединений - все пучком,
когда разрастается до 200 у некоторых норма а у некоторых вылетает постоянно, впн висит, а пинги то идут то нет....
Добавлено: Ср янв 07, 2009 2:52 pm
NiTr0
/etc/pptpd.conf:
Код: Выделить всё
option /etc/ppp/options.pptpd
logwtmp
delegate
connections 2000
/etc/ppp/options.pptpd:
Код: Выделить всё
name pptpd
require-mschap
require-chap
ms-dns 10.255.0.2
ms-dns 10.255.0.12
proxyarp
172.31.255.1:
debug
nobsdcomp
novj
novjccomp
nologfd
lcp-echo-interval 2
lcp-echo-failure 12
default-asyncmap
plugin radius.so
plugin radattr.so
В логах сообщения есть, но они, насколько я понял, от основного демона - т.к. pid один и тот же, и, очевидно, сигнализируют о кривой попытке начать коннект.
Добавлено: Чт янв 08, 2009 7:34 pm
Ali
решение оказалось гиперпростое, всю жизнь юзал патченный пппд, патченные ядра, но что с 2.6.18 мппе уже в ядро встроен ето я знал а что патчить пппд под мппе уже не знал, короче всем советую как сказал автор качать все ванильное и тогда все зашуршит... и с мппе и без, проверено!
Добавлено: Пн фев 02, 2009 5:33 pm
NiTr0
Заметил багу... При пинге адреса туннеля со стороны сервера (и ессно всего, что за ним) - периодически скачет пинг. 1 мс - норма, иногда до 10-20 и выше подпрыгивает. С 0.8.1 - пинг прыгал до 700-800 мс спустя 2-3 дня аптайма.
И еще бага - после 0.8.1 обновился на 0.8.2, стартонул сервер, заметил ругань на конфиг - остановил, killall pppd - машина ушла в краш.
Сейчас пока 0.7.13 пользую... Не считая скачущего пинга - претензий пока нет.
Добавлено: Вт фев 03, 2009 6:56 am
ran
а вы ядро патчили или просто модуль под существующее ядро собирали?
Добавлено: Вт фев 03, 2009 6:56 pm
NiTr0
Я собирал модуль. Ядро не патчил (хотя работает в непатченном виде ИМХО только из-за ошибки в pppox)
Добавлено: Ср фев 04, 2009 4:13 pm
ran
попробовал его как пптп клиента (версия 0.8.2 ядро 2.6.27) - работает вроде нормально но есть нехороший глючок: с ним перестают работать опции пппд persist holdoff maxfail
это то что сразу увидел...
Добавлено: Вт апр 07, 2009 4:13 am
yes
Ребят, помогите поставить это.
я не совсем понимаю процедуру компиляции ядра, подскажите где можно еще прочитать про этого зверька, на русском,
Если не трудно, то в кратце по шагам.
Спасибо.