Jump to content
Калькуляторы

Повторюсь, попробуйте любое 'проработанное' ядро. Не первых ревизий, 3.18.24 например.

У меня абсолютно нормально работали 3.16.хх, 3.17.хх разных ревизий, недавно вон 3.18.10 глюкануло - возможно баг в конкретном релизе, обновил на 3.18.24 пока работает нормально.

3.18.19 пока полёт нормальный.

Share this post


Link to post
Share on other sites

шейпер скриптом или accel-ем?

скриптом

 

Падало на ядрах 3.13. 3.16 3.19 4.2.

я бы тестировал на LTS ядрах в первую очередь.

 

Попробуйте 3.14 с этим патчем. По идее, должно помочь

Ну я уже перепилил шейпер, теперь qdisc-и удаляются сугубо по ip-up. Кол-во падений после этого сильно уменьшилось...

+ после перехода на 4.1.12 - все стало намного лучше.

Share this post


Link to post
Share on other sites

еще раз повторю - шейпер не при чем, у меня падало без шейпера.

Share this post


Link to post
Share on other sites

еще раз повторю - шейпер не при чем, у меня падало без шейпера.

А я еще раз говорю - там не один баг. Баг и при снятии шейпера, баг и просто при опускании ифейса, + еще несколько более глубоко закопанных багов...

Share this post


Link to post
Share on other sites

Кто-нибудь использует сабж в режиме PPPoE-сервера с поддержкой IPv6? Можно ли сделать чтобы адреса IPv4 продолжили выдаваться через радиус, а IPv6 выдавались из пула, заданного на сервере? Есть-ли какие-нибудь примеры конфигурации на этот счет? - документация на сайте весьма скудная.

Share this post


Link to post
Share on other sites

можно, ключевые элементы конфига:

[modules]

ipv6_nd

ipv6_dhcp

ipv6pool

 

[ppp]

ipv4=allow

ipv6=allow

 

[ipv6-pool]

по желанию

Share this post


Link to post
Share on other sites

за последний день 3 браса покрашилось, трейсы: http://pastebin.com/p68hNS8R http://pastebin.com/36ieRAM2 http://pastebin.com/3BRTVEB6

наверное буду на 3.2/3.4 ядро откатываться...

Написал чуваку из тех кто активно патчит сетевой стэк по теме ppp.

Выслал ему свой трейс и дал ссылку на эту тему. Предлагает писать в netdev.

It looks like __kernfs_remove() tries to take a reference on a kernfs

node that is about to be freed (i.e. with reference counter set to 0).

That could be due to the same node being freed in a loop, but I don't

know how we could get into that case (never went through the kernfs

code before).

You really should post to LKML (linux-kernel@vger.kernel.org) and

netdev (netdev@vger.kernel.org) with proper subject. You probably can

copy Greg Kroah-Hartman too (gregkh@linuxfoundation.org), as he's the

maintainer of sysfs, kernfs and driver core.

Share this post


Link to post
Share on other sites

за последний день 3 браса покрашилось, трейсы: http://pastebin.com/p68hNS8R http://pastebin.com/36ieRAM2 http://pastebin.com/3BRTVEB6

наверное буду на 3.2/3.4 ядро откатываться...

Объясни мне убогому, а зачем вообще pppoe сервера апдейтить? :)

[kayot@nas3 ~]$ cat /proc/net/pppoe | wc -l
1159
[kayot@nas3 ~]$ uptime
20:24:42 up 510 days, 16:08,  1 user,  load average: 0.00, 0.01, 0.00
[kayot@nas3 ~]$ uname -a
Linux nas3.xxx 2.6.31.9-174.1.bill.x86_64 #1 SMP Tue Dec 29 23:01:51 EET 2009 x86_64 x86_64 x86_64 GNU/Linux
[kayot@nas3 ~]$ cat /etc/redhat-release
Fedora release 12 (Constantine)
[kayot@nas3 ~]$

Кстати, судя по трейсу у тебя 32 битные ядра? Зачем оно нынче? Вполне возможна часть багов отсюда растет.

Edited by kayot

Share this post


Link to post
Share on other sites

Предлагает писать в netdev.

сегодня отписал, но похоже мэйллист умер.

 

Объясни мне убогому, а зачем вообще pppoe сервера апдейтить? :)

ради производительности же. на свежих ядрах существенно нагрузка падает.

 

Кстати, судя по трейсу у тебя 32 битные ядра? Зачем оно нынче? Вполне возможна часть багов отсюда растет.

не думаю, что отсюда - юзаю 32бит т.к. смысла от 64бит для ipv4 большого нет, а потенциально - больше cache misses из-за распухания кода.

Share this post


Link to post
Share on other sites

NiTr0

Потенциально - 32 бит код нынче мало кто тестирует, велика вероятность как раз таки собирать в одиночестве баги.

А разница в объемах кода на маршрутизацию влиять не может.

Share this post


Link to post
Share on other sites

Объясни мне убогому, а зачем вообще pppoe сервера апдейтить? :)

ради производительности же. на свежих ядрах существенно нагрузка падает.

не думаю, что отсюда - юзаю 32бит т.к. смысла от 64бит для ipv4 большого нет, а потенциально - больше cache misses из-за распухания кода.

Для современного железа это не особо актуально. На том же сервер что кидал для примера пиковая загрузка менее 10%, это при 1.5к сессий.

Share this post


Link to post
Share on other sites

Предлагает писать в netdev.

 

сегодня отписал, но похоже мэйллист умер.

 

Тоже отписался туда.

Share this post


Link to post
Share on other sites

NiTr0

А не проще ли отключить или выпилить nfs из ядра. На брасах это не самый нужный функционал.

 

А по поводу 32 битов, большинство девелоперов забили на i586 и бывают баги под 32 бита при их отсутствии на 64

Share this post


Link to post
Share on other sites

NiTr0

А не проще ли отключить или выпилить nfs из ядра. На брасах это не самый нужный функционал.

+1

2NiTr0, Вы nfs с какой целью на bras'ах пользуете?

 

NiTr0

А по поводу 32 битов, большинство девелоперов забили на i586 и бывают баги под 32 бита при их отсутствии на 64

+1

2NiTr0, я уже лет как пять назад опытным путем убедился, что есть профит от 64-битных систем на роутерах и брасах.

Памяти надо больше ставить, но не думаю, что на этом стоит экономить в текущих реалиях. Простой браса в пару минут стоит дороже пары планок памяти.

Share this post


Link to post
Share on other sites

Сижу всем зоопарком на 3.2.х ветке ванильных ядер с самого момента её появления и до сих пор с разработанными конфигами для собственных нужд и слезать не собираюсь даже тогда, когда на неё задвинут разработчики и когда её не будут поддерживать. Любые попытки соскочить с этой ветви приводили к дестабилизации работы в том или ином виде.

 

Ядра ветви 3.2.х пока юзаю разные (55, 64, 72, вчерась поставил где-то 73-е), в зависимости от ленивости. Где-то обновлял год или более назад, а где-то месяц или менее. Чисто под настроение. Глобальные обновления ядра со сменой ветви например с 3.2.х на 4.1.х или даже что-то новее на серверах авторизации считаю не особо нужными, когда там ничего кроме самой тупой авторизации и нет. Ходят себе годами туда-сюда туннели поднимают и опускают вместе с шейперами. Ну пусть этим и дальше занимаются. Апдейт ядра - это дело больше сугубо личное, чем реально необходимое.

 

Админ хоть и технарь, но существу суеверное иногда. Лично я верю в кармическую чистоту 3.2.х. Она себя зарекомендовала.

Share this post


Link to post
Share on other sites
уже лет как пять назад опытным путем убедился, что есть профит от 64-битных систем на роутерах и брасах.

Памяти надо больше ставить, но не думаю, что на этом стоит экономить в текущих реалиях. Простой браса в пару минут стоит дороже пары планок памяти.

+1

Share this post


Link to post
Share on other sites

А не проще ли отключить или выпилить nfs из ядра. На брасах это не самый нужный функционал.

что-то я не заметил в трейсах nfs.

 

2NiTr0, Вы nfs с какой целью на bras'ах пользуете?

nfs там вообще не испольуется. если и есть - то висит мертвым кодом, в юзерленде не активируется.

 

я уже лет как пять назад опытным путем убедился, что есть профит от 64-битных систем на роутерах и брасах.

попробую ради эксперимента какой-то брас на х86_64 перевести, но думаю профита с того не особо будет. + у людей и 4.1 на х86_64 крашится.

Share this post


Link to post
Share on other sites

еще раз повторю - шейпер не при чем, у меня падало без шейпера.

А я еще раз говорю - там не один баг. Баг и при снятии шейпера, баг и просто при опускании ифейса, + еще несколько более глубоко закопанных багов...

В 3.2.73 много интересных патчей. Такое ощущение, что ветка лучше всего поддерживается.

Предлагаю попробовать.

PS

Лучше х64 вариант)

Share this post


Link to post
Share on other sites

товарищи!

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

Share this post


Link to post
Share on other sites

товарищи!

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

Так кто же против)

Проблема, что пока это лотерея.

Я вообще за то, что бы не обсуждать.

Что бы все стабильно работало на всех ядрах!

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now