[kayot]

У кого accel-ppp для ipoe работает? Как нынче стабильность решения? И сколько держит сервер в нагрузке онлайн пользователей?

[kayot@IPoE1 ~]$ accel-cmd show stat
uptime: 142.22:07:11
cpu: 0%
mem(rss/virt): 458760/879524 kB
...
sessions:
 starting: 0
 active: 2535
 finishing: 0
ipoe:
 starting: 0
 active: 2535
 delayed: 0

[kayot@IPoE1 ~]$ uname -a

Linux IPoE1 3.18.24 #1 SMP Wed Nov 11 19:46:14 EET 2015 x86_64 x86_64 x86_64 GNU/Linux

Как-то так(сейчас не час пик), стабильность абсолютная.

[SyJet]

У кого accel-ppp для ipoe работает? Как нынче стабильность решения? И сколько держит сервер в нагрузке онлайн пользователей?

[kayot@IPoE1 ~]$ accel-cmd show stat
uptime: 142.22:07:11
cpu: 0%
mem(rss/virt): 458760/879524 kB
...
sessions:
 starting: 0
 active: 2535
 finishing: 0
ipoe:
 starting: 0
 active: 2535
 delayed: 0

[kayot@IPoE1 ~]$ uname -a

Linux IPoE1 3.18.24 #1 SMP Wed Nov 11 19:46:14 EET 2015 x86_64 x86_64 x86_64 GNU/Linux

Как-то так(сейчас не час пик), стабильность абсолютная.

Ухтыжка, версия accel какая? Ядро пилили или сток?

[kayot]

По-моему 1.10 релиз, релизные версии начиная с 1.9 полностью стабильны. Ядро ванильное с kernel.org

[SyJet]

По-моему 1.10 релиз, релизные версии начиная с 1.9 полностью стабильны. Ядро ванильное с kernel.org

Шейпинг/полисинг встроенный?

[kayot]

Шейпинг HTB в обе стороны своими скриптами.

[SyJet]

Шейпинг HTB в обе стороны своими скриптами.

С iptratelimit не пробовали?

[Cramac]

Всем привет. Подскажите, вчера после долгой работы помер сервер

вот что выдало

https://yadi.sk/i/vre0yDNbrUALa

[xeb]

oom-killer

закончилась память

[NiTr0]

кто-то выжрал 5 гигов?... или я неверно прочитал?

в любом случае лучше подпереть monit'ом.

[Cramac]

памяти дофига на сервере, но одно дело если бы он просто упал, так повис весь сервер.

[kayot]

Память скушал не accel а окаменевший кал 2.6.35-22

Вот зачем держать кривые дистрибутивные ядра на роутерах?

[Cramac]

сервер работает уже какой год, работал - никто не трогал :) Теперь решили обновить на свежее, заодно и accel обновить.

[hsvt]

А в чем вообще смысл держать стоковое ядро на софт-роутере? Или собирать чуть более свежее, но такое же окаменелое?

Впилите какой-нить 3.18 и забудьте о всех бедах, у меня часть машин вообще на centos 5.х живут, но с ядрами 3.18 :)

 

А на стоковом 3.10.0-327.el7.x86_64 тоже всё плохо будет при терминации PPPoE ? Что то с наскоку не разобрался, как перейти на 3.18, а в elrepo уже 4.5.2 и 4.4.8 lt. Вы вручную пересобирали и накатывали с kernel.org ?

[NiTr0]

нормально все с 3.10. если там шапочники не испохабили чего-нить.

[hsvt]

На CentOS 7.2.1511 не собирается vlan-mon из-за хедеров.

 

make: *** /usr/src/linux-headers-3.10.0-327.13.1.el7.x86_64: No such file or directory.  Stop.
make[2]: *** [drivers/vlan_mon/driver/vlan_mon.ko] Error 2
make[1]: *** [drivers/vlan_mon/CMakeFiles/vlan_mon_drv.dir/all] Error 2
make: *** [all] Error 2

 

drivers/vlan_mon/CMakeFiles/vlan_mon_drv.dir/build.make
68 cd /opt/accel-ppp/build/drivers/vlan_mon && make -C /usr/src/linux-headers-3.10.0-327.13.1.el7.x86_64 M=/opt/accel-ppp/build/drivers/vlan_mon/driver modules

 

У кентоса же хедеры лежат в /usr/src/kernels/`(uname -r)`/include

 

Если сделать симлинк, то такое:

 

make[3]: *** No rule to make target `modules'.  Stop.
make[2]: *** [drivers/vlan_mon/driver/vlan_mon.ko] Error 2
make[1]: *** [drivers/vlan_mon/CMakeFiles/vlan_mon_drv.dir/all] Error 2
make: *** [all] Error 2

 

UPD

 

Буду собирать ванильное ядро.

Изменено 6 мая, 2016 пользователем hsvt

[NiTr0]

может проще поставить какой-то роутерно-флэшечный дистр? тот же LEAF, где аксель искаропки есть?

я лично не вижу смысла держать полновесный дистр на роутерах/брасах...

[hsvt]

может проще поставить какой-то роутерно-флэшечный дистр? тот же LEAF, где аксель искаропки есть?

я лично не вижу смысла держать полновесный дистр на роутерах/брасах...

 

Я уже думал про ваш LEAF, но пока был на Debian с ядром 3.2, там отлично собирался accel последний, но надоело, да и ядро старое. CentOS более LTS как то и стабильнее. LEAF он же еще только i686 ? Надо попробовать... А так вообще перестал уже играть в эти игры c ядрами со времён Gentoo.

Изменено 6 мая, 2016 пользователем hsvt

[s.lobanov]

может проще поставить какой-то роутерно-флэшечный дистр? тот же LEAF, где аксель искаропки есть?

я лично не вижу смысла держать полновесный дистр на роутерах/брасах...

 

а смысл? экономить место? я вот не понимаю смысла вашего LEAF, bras делается без проблем и из debian и из rh-based дистрибутивов

[NiTr0]

CentOS более LTS как то

т.е. более окаменелый?

 

. LEAF он же еще только i686 ?

есть и х86_64 билд. только смысла от него мало ИМХО, разве что на ipv6 может будет прирост.

 

а смысл? экономить место?

1) надежность (нет ни непредсказуемого HDD, ни постоянно примонтированного раздела который при отключениях питания норовит повредиться).

2) легкость обслуживания

3) легкость бекапа/разворачивания из бекапа (по сути надо только leaf.cfg и configdb.lrp)

[s.lobanov]

NiTr0

Сомнительные аргументы. А вот то, что вам вдруг надоест этим заниматься и потом никто не подхватит, куда бо'льшая проблема. debian и тем более RH в этом плане куда более надёжны. Я так понимаю, вы как раз и подхватили этот дистр, когда изначальные авторы проекта забили на него?

[hsvt]

Ну перешёл я на 3.18.24, вырезал там всякие wireless, nfs, nfsd, btrfs, gpu nouveau, radeon, bluetooth, infiniband, cisco, chelsio, mellanox и прочее-прочее не нужное. Сделал binrpm-pkg, поставил kernel-3.18.24-2.x86_64.rpm kernel-devel-3.18.24-2.x86_64.rpm kernel-headers-3.18.24-2.x86_64.rpm, dracut и прочее. Система вполне штатно загрузилась, работает.

 

Собрал аццель, при make install ругается теперь только на флаг компилятора, здесь где-то такое уже проскакивало:

 

-- Installing: /usr/local/bin/accel-cmd
-- Up-to-date: /usr/local/share/man/man1/accel-cmd.1
Makefile:664: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler
Makefile:664: Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler

 

Модули ipoe\vlan_mon подгрузились, но как теперь быть уверенным в стабильной работе ОС если центос не на стоковом ядре находится, как пускать абонентов через этот сервер? RPM уже например ругался на это. Ядро которое "отполированное" в RH - оно как то проще и стабильней, но там модуль vlan_mon не собирается. А здесь теперь ждать неизвестно чего. Или может вообще лучше не трогать .config ? Кто, что скажет?

Изменено 6 мая, 2016 пользователем hsvt

[NiTr0]

А вот то, что вам вдруг надоест этим заниматься и потом никто не подхватит, куда бо'льшая проблема.

ну не я один его-то пилю. как минимум 2 активных девелопера есть еще, из основателей (это ~15 лет назад).

 

debian и тем более RH в этом плане куда более надёжны

ну вот человек мучается, ядра конпеляет зачем-то...

 

так понимаю, вы как раз и подхватили этот дистр, когда изначальные авторы проекта забили на него?

нет, просто девелоперы не слазили с 2.4 ветки.

 

Ядро которое "отполированное" в RH - оно как то проще и стабильней

ванильные ядра-то чем нестабильны? аптайм - годы. или по принципу "если туда напилили 100500 патчей на kvm/openvz - значит это круто"?

[kayot]

+1, стоковые центосовские ядра вовсе не эталон. Скорее наоборот, я его слепила что бы было.

[Dimka88]

Нужно Больше срачика на тему ядра и дистрибутивов. Там еще accel-ppp + dpdk xeb пилит, открывается еще шире полигон для обсуждения.

В чем проблема скомпилировать только то, что нужно каждому? gentoo, crux, lfs и ванильное ядро. Кому вообще параллельно, как там все работает, тот ставит на debian или покупает железный NAS/BRAS.

[NiTr0]

стоковые центосовские ядра вовсе не эталон. Скорее наоборот, я его слепила что бы было.

угу, я пару раз натыкался на багу, внесенную багфиксом; из того что запомнилось - kvm заломали, х86 гости в панику падать начали (из федоры бэкпортировали глюк), и баге той было несколько месяцев на момент ее "обнаружения" мной, нагуглил тикет федоры где саппорт культурно слал всех в сад ("у вас гость не RHEL/федора? так пишите туда, и пофиг что раньше работало а после апдейта хоста сломалось") либо отмалчивался. откатился взад. не, потом когда через полгода-год обновился, это уже исправили, но осадок остался.

 

так что обилие работы над окаменелой версией - не всегда признак стабильности, в случае шапки это скорее мышиная возня бэкпортирования нового функционала на старый ABI.