aabc Posted March 16, 2009 Posted March 16, 2009 (edited) ipt_netflow немного поругался на буфер отправки, подправил значение и все.при работе в консоли чувствуются легкие тормоза, хотя загрузка относительно процессора невысокая. Попробуйте увеличить размер хэш таблицы (в два раза больше чем кол-во потоков), по умолчанию она не оптимального, а минимального размера. Edited March 16, 2009 by aabc Вставить ник Quote
witos Posted March 16, 2009 Posted March 16, 2009 r67 | xebd | 2009-03-13 17:40:16 +0300 (Птн, 13 Мар 2009) | 2 lines updated ppp-allow-mppe.patch Сейчас робит правильно, разрешает подключаться как с mppe, так и без него. Спасибо! Вставить ник Quote
xeb Posted March 17, 2009 Posted March 17, 2009 Дык и курим, и чем больше курим тем больше желание снести нахрен этот плугин и начать кивирять с нуля свою реализацию ибо там сам чёрт ногу сломит. я уже этим занимаюсь Вставить ник Quote
NiTr0 Posted March 18, 2009 Posted March 18, 2009 (edited) Кто-то еще замечал периодические задержки пинга через туннель? Пример - пингуется абонент с сервера (или наоборот), задержка - 0.5-1-2 мс пакетами по 64 байта, вдруг - проскакивает пакет 10-15-20-30 мс или более, дальше - опять 0.5-1-2 мс... Где-то 1 из 20-30 пакетов... Наблюдается как на 1-ядерном сервере (атлон 3000+, 500 клиентов - задуман изначально как резервный) с 0.7.13, так и на 2-ядерном (атлон 5600+ с 10 клиентами, тестируется на стабильность) с r66. Edited March 18, 2009 by NiTr0 Вставить ник Quote
SokolovS Posted March 18, 2009 Posted March 18, 2009 У меня небыло таких проблем. пингую например Яндекс пакетами по 1024 байта с частотой 1 пакет в 0.01 сеек. ping -s 1024 -c 1000 -i 0.01 yandex.ru --- yandex.ru ping statistics --- 1000 packets transmitted, 1000 received, 0% packet loss, time 13535ms rtt min/avg/max/mdev = 23.228/24.710/33.835/1.395 ms, pipe 3 Вставить ник Quote
martin74 Posted March 18, 2009 Posted March 18, 2009 accel-pptpd нормально дружит с ip_nat_pptp? Вставить ник Quote
sfstudio Posted March 18, 2009 Posted March 18, 2009 accel-pptpd нормально дружит с ip_nat_pptp? На 2.6 в режиме сервера проблем не заметил. На 2.4 в режиме клиента проблем и чудес немеряно. Причём глюки весьма разнообразные. Частично решается заворачиванимем всех пакетов из OUTPUT в NOTRACK (patch-o-matic). Вставить ник Quote
martin74 Posted March 18, 2009 Posted March 18, 2009 у меня сервера под centos 5.2 64 bit... Вот если бы еще спеки для сборки рпм были... Я бы уже перешел на него. Очень не люблю софт не из рпм... Вставить ник Quote
sfstudio Posted March 18, 2009 Posted March 18, 2009 у меня сервера под centos 5.2 64 bit... Вот если бы еще спеки для сборки рпм были... Я бы уже перешел на него. Очень не люблю софт не из рпм... Откройте для себя checkinstall. Вставить ник Quote
martin74 Posted March 18, 2009 Posted March 18, 2009 открыл. показать результаты? заворачивание в пакет /bin/df и аналогичных.... Вставить ник Quote
sfstudio Posted March 18, 2009 Posted March 18, 2009 открыл. показать результаты? заворачивание в пакет /bin/df и аналогичных.... А мне-то зачем ваши результаты? У меня и без них всё собирается и заворачивается да и вообще пересборкой и накладыванием сторонних патчей у меня занимается dkms (уж незнаю как там в центоси). Вставить ник Quote
NiTr0 Posted March 19, 2009 Posted March 19, 2009 У меня небыло таких проблем. пингую например Яндекс пакетами по 1024 байта с частотой 1 пакет в 0.01 сеек. Пропингуйте IP туннеля со стороны сервера. Возможно на инет оно не так отчетливо заметно... Вставить ник Quote
shicoy Posted March 20, 2009 Posted March 20, 2009 Через 21 день аптайма кернел паник. к сожалению железка стоит в эксплуатации и пришлось равшану ее экстренно перегрузить, дамп экрана снять не успел. но пока работала держала до 1200 тунелей. Вставить ник Quote
sdy_moscow Posted March 20, 2009 Posted March 20, 2009 да я тоже паники уже наблюдал на 2-х железяках... но дампы по той-же причине не удалось снять. Сейчас сказал пересобрать ядра с дампом паники на диск. Вставить ник Quote
sirmax Posted March 22, 2009 Posted March 22, 2009 Хм, вылезла странная проблема Часть клиентов с шифрованием не работают (ppp поднимается, но траффик не ходит) Если смотреть tcpdump со стороны сервера, то выглядит как будто все ОК, т.е. клиент судя по всему получает траффик но по какой то причине не может его обработать. При этом, при конекте на другие VPN-сеовера все ОК (с шифрованием) После обновления accel-pptp до последней версии из svn c опцией allow-mppe-128 вместо requie - при включеном шифровании, соединение проходит нормально и висит но траффика нет (выглядит как файрволл на строне клиента) - при отключенном шифровании - все сразуначинает работать. Вставить ник Quote
sirmax Posted March 22, 2009 Posted March 22, 2009 Похоже что проблема с 64-разрядными версиями виндоуз upd Не.. не только ( Хм... Как дебагать неясно ( Вставить ник Quote
PhantomTLT Posted March 23, 2009 Posted March 23, 2009 да я тоже паники уже наблюдал на 2-х железяках... но дампы по той-же причине не удалось снять. Сейчас сказал пересобрать ядра с дампом паники на диск. Таже самая фигня. Похоже медленно, но верно утекает память (если верить данным мониторинга). Правда дамп тоже не видел. Вставить ник Quote
sirmax Posted March 23, 2009 Posted March 23, 2009 Хм, у меня - нет. sirmax@skuld ~ $ w 09:50:36 up 44 days, 16:42, 975 users, load average: 0,42, 0,21, 0,12 Вставить ник Quote
sdy_moscow Posted March 23, 2009 Posted March 23, 2009 да я тоже паники уже наблюдал на 2-х железяках... но дампы по той-же причине не удалось снять. Сейчас сказал пересобрать ядра с дампом паники на диск. Таже самая фигня. Похоже медленно, но верно утекает память (если верить данным мониторинга). Правда дамп тоже не видел. Я не уверен, но мне показалось что повисает из-за локировок. Вставить ник Quote
PhantomTLT Posted March 23, 2009 Posted March 23, 2009 Я не уверен, но мне показалось что повисает из-за локировок. Локи (softlock) были. Исчезли (из логов) после обновления glibc до glibc-2.8_p20080602-r1. Но все равно осталось: pptpctrl[20317]: segfault at 0 ip 00007f38c8c707f4 sp 00007fffd115a708 error 4 in libc-2.8.so[7f38c8bf8000+13f000] Появляется когда свободной памяти становится мало. Если посмотреть график - то каждый день уровень свободной памяти становится все меньше и меньше. Как достигает минимума - сначала такие ошибки, а затем сервер умирает. Вставить ник Quote
NiTr0 Posted March 24, 2009 Posted March 24, 2009 Еще заметил странность - подозреваю, связанную с сетевухой: при 500+ клиентах - ksoftirqd на 1 ядре ядре отжирал 80-90% времени... 0 ядро гуляло... При 300 клиентах - такого не наблюдается, сервер практически гуляет. Попробую с опциями сетевухи побаловаться, чтобы уменьшить кол-во прерываний (стоит интел гигабитка). Вставить ник Quote
SokolovS Posted March 25, 2009 Posted March 25, 2009 Драйвер то для интел-сетевухи с NAPI? Вставить ник Quote
NiTr0 Posted March 25, 2009 Posted March 25, 2009 Драйвер из ядра, 2.6.27. Пересобрал модулем, указал при загрузке параметры (побольше буффер передачи/приема, задержка прерываний от 32 мкс, + увеличил латентность PCI), посмотрю как себя вести будет... Вставить ник Quote
SokolovS Posted March 25, 2009 Posted March 25, 2009 1. Лучше брать сорцы с сайта Intel. 2. Обязательно юзать NAPI Вставить ник Quote
NiTr0 Posted March 30, 2009 Posted March 30, 2009 (edited) Таки проблема не решилась при пересборке с NAPI, при кол-ве сессий более 400 - резко растет загрузка проца ksoftirqd :( Edited March 31, 2009 by NiTr0 Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.