В общем пытался оптимизировать связку pptp+pppd+kernel и наткнулся на проект accel-pptp, по словам автора понял что это ядерный pptp, даже при нагрузке в 1200 коннектов загрузка процессор, память упала на 50 % также оптимизирована производительность с одного соединения удается получить до 7 ~ 8 МБ/сек. Хотя на странице проекта зафиксирована 11 МБ/сек.
Я пропатчил ядро и установил сабж, действительно производительность увеличилась при этом процессор отдыхал.
Если кому то интересно по тестируйте зверька, поделимся результатами!
Страница проекта http://accel-pptp.sourceforge.net/
Использование альтернативного демона pptpd accel-pptpd
Интересно, поставлю на тестовую машинку, потестирую... Т.к. с оригинальным pptpd у меня имеется некий странный геморрой по части производительности - чем больше аптайм, тем больше грузится проц, и 500 сессий с 110 мбит суммарного трафа практически полностью загружают атлон 5600+.
Сколько у вас клиентов это чудо тянуло, на какой машине, какой траф и какая загрузка проца была?
Сколько у вас клиентов это чудо тянуло, на какой машине, какой траф и какая загрузка проца была?
Я проверял косвенным методом, использовал обычный 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 приводит к деградации сервиса при большом количестве активных пользователей также зависящее от ширины канала!
То есть как вы говорили
Опять таки может я не прав но многие факты свидетельствуют об этом !
Вот к примеру один из них!
http://misc-heap.blogspot.com/2008/04/p ... linux.html
Пробовал качать файлы:
так вот с обычного 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 приводит к деградации сервиса при большом количестве активных пользователей также зависящее от ширины канала!
То есть как вы говорили
Так вот при использовании обычного poptop с его userlevel обработкой ip_gre трафика мне кажется что если ваш канал будет увеличиваться то это приведет к деградации NAS Сервера какой бы мощный он не был.NiTr0 писал(а):Чем больше аптайм, тем больше грузится проц, и 500 сессий с 110 мбит суммарного трафа практически полностью загружают атлон 5600+.
Опять таки может я не прав но многие факты свидетельствуют об этом !
Вот к примеру один из них!
http://misc-heap.blogspot.com/2008/04/p ... linux.html
Поставил на резервную машину (атлон 3000+), с некоторыми шаманствами (инсталлка под 64бит ОС криво работает) - вроде как работает... завтра основную массу клиентов перекину на ту машинку, посмотрю на загрузку (500 чел грузят атлон 5600+ на 85-90%, хотя основная загрузка идет на software interrupts...)
ребята а етот впн понимает мcчап-v2 и mppe ?NiTr0 писал(а):Итак, на сервере 426 пользователей, траффик - порядка 80 мбит суммарный, загрузка проца - чуть больше 18%... Хотя кое-кто из людей жаловался на ошибки соединения - но их источник пока не выяснен (возможно, глюки локалки).
При 463 юзерах - загрузка проца 22%, траффик - около тех же 80 мбит...
знаю что мппе зло но на данный момент многие клиенты на нем сидят, и всех обзвонить и переделать настройки почти нереально (
ИМХО - должен, т.к. это - тот же поптоп, только с вынесенным в модуль ядра кодом работы с туннелями.c MPPE пашет, все в норме, разгрузка проца колоссальная, была загрузка 10-20% теперь упала до 1-2%, но есть какие-то странности отваливаются некоторые юзеры вот что обнаружил в логахNiTr0 писал(а): P.S. Аптайм уже 2 недели - проблем нет.
MGR: dropped slow initial connection
MGR: dropped small initial connection
пинги в инет уходят пачками, 30 пингов прошло потом затык итд...
не пойму че такое.... пробовал и с мппе и без, не в нем дело,
поделитесь у кого какой конфиг что ли
причем когда мало впн-соединений - все пучком,
когда разрастается до 200 у некоторых норма а у некоторых вылетает постоянно, впн висит, а пинги то идут то нет....
/etc/pptpd.conf:
/etc/ppp/options.pptpd:
В логах сообщения есть, но они, насколько я понял, от основного демона - т.к. pid один и тот же, и, очевидно, сигнализируют о кривой попытке начать коннект.
Код: Выделить всё
option /etc/ppp/options.pptpd
logwtmp
delegate
connections 2000Код: Выделить всё
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Заметил багу... При пинге адреса туннеля со стороны сервера (и ессно всего, что за ним) - периодически скачет пинг. 1 мс - норма, иногда до 10-20 и выше подпрыгивает. С 0.8.1 - пинг прыгал до 700-800 мс спустя 2-3 дня аптайма.
И еще бага - после 0.8.1 обновился на 0.8.2, стартонул сервер, заметил ругань на конфиг - остановил, killall pppd - машина ушла в краш.
Сейчас пока 0.7.13 пользую... Не считая скачущего пинга - претензий пока нет.
И еще бага - после 0.8.1 обновился на 0.8.2, стартонул сервер, заметил ругань на конфиг - остановил, killall pppd - машина ушла в краш.
Сейчас пока 0.7.13 пользую... Не считая скачущего пинга - претензий пока нет.
это то что сразу увидел...