[Abram]

Думается, захлебнется ваш квад...

Кстати, заметил такую штуку - если уж NAS захлебнулся и зарылся в softirq etc., то это уже всё. Надо конкретно снижать нагрузку, чтобы разгребся, после чего можно грузить опять.

Посему второй NAS таки нужен. Хотя бы на виртуальной машине где-нибудь, чтобы время от времени кусок нагрузки сбросить.

[vadimus]

Интересно, сколько сессий потянет комп с 2хW5590 (топовый XEON) при безлимитах от 5 Мбит/с... Кто бы попробовал? =)

[xeb]

итак тестируем 0.8.5-rc1

Author: Kozlov Dmitry <dima@server>
Date:   Wed Dec 2 18:45:10 2009 +0300

    using per-cpu threads for packet receiveing/transmiting

приём/передача пакетов перенесена в потоки, это позволит избавиться от soft lockup'ов, но в случае возникновения петли проц будет пожираться неимоверно, так что не забываем:

iptables -A INPUT -s <ип адраса впн юзеров> -p tcp --dport 1723 -j DROP

так-же, я думаю, должна повыситься балансировка по ядрам на многоядерных системах

синтетическим тестом на 500 коннектах 4х3ГГц комп выжал гигабит/110кппс при загрузке 70%

если кто может предоставить тестовый стенд из трёх четерёхядерников, было бы не плохо :)

 

[sfstudio]

УУУПС 2.6.19:

drivers/net/pptp.c: In function 'worker_thread_tx':

drivers/net/pptp.c:1049: error: request for member 'dev' in something not a structure or union

 

Это строка:

NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, skb->dst.dev, dst_output);

 

Судя по skb->dst = &rt->u.dst; строка должна выглядеть так:

NF_HOOK(PF_INET, NF_IP_LOCAL_OUT, skb, NULL, skb->dev, dst_output);

[sfstudio]

Поправил, собрал - работает.

[Cayz]

Cayz, от тебя хотельсь бы увидеть последние логи подключений перед падением, правила iptables, настройки шейперов

в любом случае подобные извороты нужно запретить: iptables -A INPUT -s <ип адраса впн юзеров> -p tcp --dport 1723 -j DROP

Понятно, у меня так всё и было, но логи всё равно отправил в ЛС, на всяк случай.

[heap]

итак тестируем 0.8.5-rc1

Author: Kozlov Dmitry <dima@server>
Date:   Wed Dec 2 18:45:10 2009 +0300

    using per-cpu threads for packet receiveing/transmiting

приём/передача пакетов перенесена в потоки, это позволит избавиться от soft lockup'ов, но в случае возникновения петли проц будет пожираться неимоверно, так что не забываем:

iptables -A INPUT -s <ип адраса впн юзеров> -p tcp --dport 1723 -j DROP

так-же, я думаю, должна повыситься балансировка по ядрам на многоядерных системах

синтетическим тестом на 500 коннектах 4х3ГГц комп выжал гигабит/110кппс при загрузке 70%

если кто может предоставить тестовый стенд из трёх четерёхядерников, было бы не плохо :)

А можно для тех кто в танке подробнее. Разнесли в потоки и избавились от локапов, но в фаере тоже дропаем. Значит я так понял была вероятность и других локапов, не зависимо от петель? Какого плана это были грабли?

[Victor Safronov]

Не могу собрать последнюю версию драйвера в ядре 2.6.18

/home/vitek/soft/accel-pptp/kernel/driver/pptp.c: In function ‘worker_thread_tx’:

/home/vitek/soft/accel-pptp/kernel/driver/pptp.c:1129: error: request for member ‘dev’ in something not a structure or union

Предпоследняя собирается без проблем.

[sfstudio]

См мой пост, я даже написал что поправить =)

[shicoy]

Народ у кого как полет на 0.8.5-rc1?

[sfstudio]

Пока нормуль.

[Victor Safronov]

См мой пост, я даже написал что поправить =)

Я буду внимательнее читать тему, я буду внимательнее читать тему, я буду внимательнее читать тему, я буду внимательнее читать тему, я буду внимательнее читать тему, я буду внимательнее читать тему.

Спасибо. :))

Изменено 5 декабря, 2009 пользователем Victor Safronov

[theMIROn]

итак тестируем 0.8.5-rc1

Author: Kozlov Dmitry <dima@server>
Date:   Wed Dec 2 18:45:10 2009 +0300

    using per-cpu threads for packet receiveing/transmiting

приём/передача пакетов перенесена в потоки, это позволит избавиться от soft lockup'ов

включение kthread полностью отломило поддержку 2.4 ядра...

 

[heap]

Пока нормуль.

Я чего-то в этой жизни определенно не понимаю.

До появления текущей версии балансировал нагрузку при помощи bonding. Нагрузка даже в пиках была на 6 из 8 ядер не более 50 процентов.

С текущей доблестной версией совместно с bonding имеем странный пейзаж. Честно загружены все 8 ядер, но в далеко не пиковой нагрузке на 50-60%, в top вижу треды по два на каждое процессорное ядро pptp 30-35%, а по каждому CPU:

нагрузка system 40-50%, в soft interrupt свои проценты по 20-30. В топ проскакивает регулярно на 100% нагруженный events или ksoftirqd. При этом в спидтесте у клиентов тоже довольно тоскливо все было.

В итоге когда попытался всю эту историю остановить мы плавно вылетели в fixed recursive fault but reboot needed.

Откатился на старую версию (0.8.4) - жизнь наладилась - два ядра практически в 0, остальные 6 10-20% и не выше и на спидтестах у клиентов все в норме.

Откуда вопрос - есть ли мысли не тему, что послужило причиной подобного бесчинства, поддается ли это фиксингу и если нет - нельзя ли сделать подробный трединг опциональным (либо при сборке, либо при загрузке модуля)? Надо тредить - задал ключ, не надо - не задал.

[DpakoH]

в одну сторону гигабит, в другую примерно 0.7, до 5к сессий

Я бы посоветовал распараллелить на 2 наса. Думается, захлебнется ваш квад...

Есть возможность поставить второй камень.

[xeb]

Я чего-то в этой жизни определенно не понимаю.

значит эксперимент не удался ...

 

[heap]

Я чего-то в этой жизни определенно не понимаю.

значит эксперимент не удался ...

 

xeb, как насчет все-таки поступить следующим образом. Продолжить развивать эту идею, но заявить ее как девелопмент и организовать ее включение при сборке по ключу. По дефолту собирать вариацию со старым механизмом. Добровольцы обкатают новую возможность, возможно в итоге оно обкатается и будет очень полезно.

[sfstudio]

На 400МГц RTL с новым механизмом производительность выше.

[theMIROn]

На 400МГц RTL с новым механизмом производительность выше.

в обе стороны? более точные цифры можешь предоставить с технологией проверки?

можно подумать и о бэкпорте на 2.4

[sfstudio]

RTL8671BH 400МГц CPU 175Hz BUS CLOCK, mppe - ~24мбит/с на старом около 18мбит при этом нагрузка скачет на старом. На новом грузит проц равномерно. Тестит iperf с -d ключём т.е. dual. Ядро 2.6.19.7

[theMIROn]

достаточно понятно, очередь захлебывается входящим трафиком, который равномерно (с полной загрузкой) отрабатывается в отдельном потоке с повышенным приоритетом, не мешая исходящему.

с другой стороны текущая реализация всегда возвращает NET_RX_SUCCESS при приеме, куда же улетают дропнутые пакеты?

 

p.s чтото скорость маловата для 400Mhz, сколько богомипсов? на BCM4704/BCM4780 @ 300mhz под ~50+ мбит/с на 2.4.37 ядре, правда без mppe и не указано с каким именно ключем

Изменено 5 декабря, 2009 пользователем theMIROn

[sfstudio]

~ # cat /proc/cpuinfo

system type : RTL8672

processor : 0

cpu model : R3000 V0.0

BogoMIPS : 398.95

wait instruction : no

microsecond timers : no

tlb_entries : 32

extra interrupt vector : no

hardware watchpoint : no

ASEs implemented :

VCED exceptions : not available

VCEI exceptions : not available

 

 

 

Без mppe и NAT и будет около 50Мбит/c

[Cayz]

Возможные коннекты на сервер через уже установленный тунель были порезаны, iptables...1723...DROP, однако...

Ещё два падения, вчера и сегодня.

Повтороно пересмотрел логи, пока нашел только одну штуку: операторы по ошибке дали клиенту на интерфейс и на впн один и тот же IP, т.е. клиент к примеру коннектясь с 10.92.169.27, получал через pptp такой же ip, знаю как реагирует на ээто XP - говорит обнаружены совпадающие имена и отваливается. у клиента этого установлена семёрка, хотя к падениям это не приводило судя по логам, но всё же... может быть это причиной или нет? сейчас устранил эту ошибку, будем смотреть дальше, время покажет...

[true.ru]

кто-нибудь сталкивался/решил с проблемой нестабильного соединения dlink dir-100 и bras с accel-pptp?

в теме есть совет с помощью iptables увеличить время ожидания соединения. не помогло.

на форуме dlink прочитал наблюдение о том, что dir-100 gre сессии поддерживает с помощью одного того же id.

 

ЗЫ с подобной проблемой позже обратился юзер с ASUS RX3041, затем с freebsd+mpd.

перевели их на bras, который работает на стоковом pptp.

[Abram]

кто-нибудь сталкивался/решил с проблемой нестабильного соединения dlink dir-100 и bras с accel-pptp?

У меня всё ещё круче - два сервера с accel-pptpd, на одном из них DIR-120 работает нормально, на другом - тупо не принимает входящие пакеты :).

При чем, разные роутеры по-разному воспринимают то один, то другой сервер.