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

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

Попробуйте увеличить размер хэш таблицы (в два раза больше чем кол-во потоков), по умолчанию она не оптимального, а минимального размера.
Изменено пользователем aabc

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

r67 | xebd | 2009-03-13 17:40:16 +0300 (Птн, 13 Мар 2009) | 2 lines

updated ppp-allow-mppe.patch

Сейчас робит правильно, разрешает подключаться как с mppe, так и без него.

Спасибо!

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

я уже этим занимаюсь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кто-то еще замечал периодические задержки пинга через туннель? Пример - пингуется абонент с сервера (или наоборот), задержка - 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.

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня небыло таких проблем. пингую например Яндекс пакетами по 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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

accel-pptpd нормально дружит с ip_nat_pptp?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

accel-pptpd нормально дружит с ip_nat_pptp?

На 2.6 в режиме сервера проблем не заметил. На 2.4 в режиме клиента проблем и чудес немеряно. Причём глюки весьма разнообразные. Частично решается заворачиванимем всех пакетов из OUTPUT в NOTRACK (patch-o-matic).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня сервера под centos 5.2 64 bit... Вот если бы еще спеки для сборки рпм были... Я бы уже перешел на него. Очень не люблю софт не из рпм...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у меня сервера под centos 5.2 64 bit... Вот если бы еще спеки для сборки рпм были... Я бы уже перешел на него. Очень не люблю софт не из рпм...

Откройте для себя checkinstall.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

открыл. показать результаты?

заворачивание в пакет /bin/df и аналогичных....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

открыл. показать результаты?

заворачивание в пакет /bin/df и аналогичных....

А мне-то зачем ваши результаты? У меня и без них всё собирается и заворачивается да и вообще пересборкой и накладыванием сторонних патчей у меня занимается dkms (уж незнаю как там в центоси).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

У меня небыло таких проблем. пингую например Яндекс пакетами по 1024 байта с частотой 1 пакет в 0.01 сеек.

Пропингуйте IP туннеля со стороны сервера. Возможно на инет оно не так отчетливо заметно...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Через 21 день аптайма кернел паник.

к сожалению железка стоит в эксплуатации и пришлось равшану ее экстренно перегрузить, дамп экрана снять не успел.

но пока работала держала до 1200 тунелей.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да я тоже паники уже наблюдал на 2-х железяках... но дампы по той-же причине не удалось снять. Сейчас сказал пересобрать ядра с дампом паники на диск.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм, вылезла странная проблема

Часть клиентов с шифрованием не работают (ppp поднимается, но траффик не ходит)

Если смотреть tcpdump со стороны сервера, то выглядит как будто все ОК, т.е. клиент судя по всему получает траффик но по какой то причине не может его обработать.

 

При этом, при конекте на другие VPN-сеовера все ОК (с шифрованием)

После обновления accel-pptp до последней версии из svn c опцией allow-mppe-128 вместо requie

- при включеном шифровании, соединение проходит нормально и висит но траффика нет (выглядит как файрволл на строне клиента)

- при отключенном шифровании - все сразуначинает работать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Похоже что проблема с 64-разрядными версиями виндоуз

 

upd

Не.. не только ( Хм...

Как дебагать неясно (

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да я тоже паники уже наблюдал на 2-х железяках... но дампы по той-же причине не удалось снять. Сейчас сказал пересобрать ядра с дампом паники на диск.

Таже самая фигня. Похоже медленно, но верно утекает память (если верить данным мониторинга). Правда дамп тоже не видел.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Хм, у меня - нет.

sirmax@skuld ~ $ w
09:50:36 up 44 days, 16:42, 975 users,  load average: 0,42, 0,21, 0,12

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да я тоже паники уже наблюдал на 2-х железяках... но дампы по той-же причине не удалось снять. Сейчас сказал пересобрать ядра с дампом паники на диск.

Таже самая фигня. Похоже медленно, но верно утекает память (если верить данным мониторинга). Правда дамп тоже не видел.

Я не уверен, но мне показалось что повисает из-за локировок.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я не уверен, но мне показалось что повисает из-за локировок.

Локи (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]

 

Появляется когда свободной памяти становится мало. Если посмотреть график - то каждый день уровень свободной памяти становится все меньше и меньше.

Как достигает минимума - сначала такие ошибки, а затем сервер умирает.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще заметил странность - подозреваю, связанную с сетевухой: при 500+ клиентах - ksoftirqd на 1 ядре ядре отжирал 80-90% времени... 0 ядро гуляло... При 300 клиентах - такого не наблюдается, сервер практически гуляет.

Попробую с опциями сетевухи побаловаться, чтобы уменьшить кол-во прерываний (стоит интел гигабитка).

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Драйвер то для интел-сетевухи с NAPI?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Драйвер из ядра, 2.6.27.

Пересобрал модулем, указал при загрузке параметры (побольше буффер передачи/приема, задержка прерываний от 32 мкс, + увеличил латентность PCI), посмотрю как себя вести будет...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1. Лучше брать сорцы с сайта Intel.

2. Обязательно юзать NAPI

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Таки проблема не решилась при пересборке с NAPI, при кол-ве сессий более 400 - резко растет загрузка проца ksoftirqd :(

 

Изменено пользователем NiTr0

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.