kayot Опубликовано 28 апреля, 2016 · Жалоба У кого 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 Как-то так(сейчас не час пик), стабильность абсолютная. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 28 апреля, 2016 · Жалоба У кого 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 какая? Ядро пилили или сток? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 28 апреля, 2016 · Жалоба По-моему 1.10 релиз, релизные версии начиная с 1.9 полностью стабильны. Ядро ванильное с kernel.org Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 28 апреля, 2016 · Жалоба По-моему 1.10 релиз, релизные версии начиная с 1.9 полностью стабильны. Ядро ванильное с kernel.org Шейпинг/полисинг встроенный? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 28 апреля, 2016 · Жалоба Шейпинг HTB в обе стороны своими скриптами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SyJet Опубликовано 28 апреля, 2016 · Жалоба Шейпинг HTB в обе стороны своими скриптами. С iptratelimit не пробовали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 мая, 2016 · Жалоба Всем привет. Подскажите, вчера после долгой работы помер сервер вот что выдало https://yadi.sk/i/vre0yDNbrUALa Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
xeb Опубликовано 4 мая, 2016 · Жалоба oom-killerзакончилась память Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 4 мая, 2016 · Жалоба кто-то выжрал 5 гигов?... или я неверно прочитал? в любом случае лучше подпереть monit'ом. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 мая, 2016 · Жалоба памяти дофига на сервере, но одно дело если бы он просто упал, так повис весь сервер. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 4 мая, 2016 · Жалоба Память скушал не accel а окаменевший кал 2.6.35-22 Вот зачем держать кривые дистрибутивные ядра на роутерах? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Cramac Опубликовано 4 мая, 2016 · Жалоба сервер работает уже какой год, работал - никто не трогал :) Теперь решили обновить на свежее, заодно и accel обновить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 5 мая, 2016 · Жалоба А в чем вообще смысл держать стоковое ядро на софт-роутере? Или собирать чуть более свежее, но такое же окаменелое? Впилите какой-нить 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 ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 5 мая, 2016 · Жалоба нормально все с 3.10. если там шапочники не испохабили чего-нить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 5 мая, 2016 (изменено) · Жалоба На 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 6 мая, 2016 · Жалоба может проще поставить какой-то роутерно-флэшечный дистр? тот же LEAF, где аксель искаропки есть? я лично не вижу смысла держать полновесный дистр на роутерах/брасах... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 6 мая, 2016 (изменено) · Жалоба может проще поставить какой-то роутерно-флэшечный дистр? тот же LEAF, где аксель искаропки есть? я лично не вижу смысла держать полновесный дистр на роутерах/брасах... Я уже думал про ваш LEAF, но пока был на Debian с ядром 3.2, там отлично собирался accel последний, но надоело, да и ядро старое. CentOS более LTS как то и стабильнее. LEAF он же еще только i686 ? Надо попробовать... А так вообще перестал уже играть в эти игры c ядрами со времён Gentoo. Изменено 6 мая, 2016 пользователем hsvt Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 мая, 2016 · Жалоба может проще поставить какой-то роутерно-флэшечный дистр? тот же LEAF, где аксель искаропки есть? я лично не вижу смысла держать полновесный дистр на роутерах/брасах... а смысл? экономить место? я вот не понимаю смысла вашего LEAF, bras делается без проблем и из debian и из rh-based дистрибутивов Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 6 мая, 2016 · Жалоба CentOS более LTS как то т.е. более окаменелый? . LEAF он же еще только i686 ? есть и х86_64 билд. только смысла от него мало ИМХО, разве что на ipv6 может будет прирост. а смысл? экономить место? 1) надежность (нет ни непредсказуемого HDD, ни постоянно примонтированного раздела который при отключениях питания норовит повредиться). 2) легкость обслуживания 3) легкость бекапа/разворачивания из бекапа (по сути надо только leaf.cfg и configdb.lrp) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 6 мая, 2016 · Жалоба NiTr0 Сомнительные аргументы. А вот то, что вам вдруг надоест этим заниматься и потом никто не подхватит, куда бо'льшая проблема. debian и тем более RH в этом плане куда более надёжны. Я так понимаю, вы как раз и подхватили этот дистр, когда изначальные авторы проекта забили на него? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
hsvt Опубликовано 6 мая, 2016 (изменено) · Жалоба Ну перешёл я на 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 6 мая, 2016 · Жалоба А вот то, что вам вдруг надоест этим заниматься и потом никто не подхватит, куда бо'льшая проблема. ну не я один его-то пилю. как минимум 2 активных девелопера есть еще, из основателей (это ~15 лет назад). debian и тем более RH в этом плане куда более надёжны ну вот человек мучается, ядра конпеляет зачем-то... так понимаю, вы как раз и подхватили этот дистр, когда изначальные авторы проекта забили на него? нет, просто девелоперы не слазили с 2.4 ветки. Ядро которое "отполированное" в RH - оно как то проще и стабильней ванильные ядра-то чем нестабильны? аптайм - годы. или по принципу "если туда напилили 100500 патчей на kvm/openvz - значит это круто"? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 6 мая, 2016 · Жалоба +1, стоковые центосовские ядра вовсе не эталон. Скорее наоборот, я его слепила что бы было. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Dimka88 Опубликовано 6 мая, 2016 · Жалоба Нужно Больше срачика на тему ядра и дистрибутивов. Там еще accel-ppp + dpdk xeb пилит, открывается еще шире полигон для обсуждения. В чем проблема скомпилировать только то, что нужно каждому? gentoo, crux, lfs и ванильное ядро. Кому вообще параллельно, как там все работает, тот ставит на debian или покупает железный NAS/BRAS. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 6 мая, 2016 · Жалоба стоковые центосовские ядра вовсе не эталон. Скорее наоборот, я его слепила что бы было. угу, я пару раз натыкался на багу, внесенную багфиксом; из того что запомнилось - kvm заломали, х86 гости в панику падать начали (из федоры бэкпортировали глюк), и баге той было несколько месяцев на момент ее "обнаружения" мной, нагуглил тикет федоры где саппорт культурно слал всех в сад ("у вас гость не RHEL/федора? так пишите туда, и пофиг что раньше работало а после апдейта хоста сломалось") либо отмалчивался. откатился взад. не, потом когда через полгода-год обновился, это уже исправили, но осадок остался. так что обилие работы над окаменелой версией - не всегда признак стабильности, в случае шапки это скорее мышиная возня бэкпортирования нового функционала на старый ABI. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...