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

Linux 3.0.x/3.1.x стабильность/багофичи

Назрел вопрос: кто-то пользовал на боевых серверах или тестовых брасах/роутерах/бордюрах 3.0.х/3.1.х ядра? Какие вылазили грабли? Пригодно вообще к пользованию под нагрузкой, или ожидать релиза 3.2 (3.3, 3.4...)?

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

Ну, мы допустим проактивно используем BLACKHOLE, fail2ban/ipset, и быструю очистку таблицы сессий для ушедших в дырку через conntrack-tools, школоботы загнивают максимум на 65xxx попытке коннекта с дыркой, на пропущенных в дырку по ipset ставится NOTRACK.

 

По теме - а чем 2.6.32 из RH6 не устраивает? Некоторые сетевые плюшки можно и руками бэкпортировать, не жертвуя стабильностью.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

У меня есть 3 или 4 роутера, никаких багов не заметил.

Share this post


Link to post
Share on other sites

Я попробовал Ubuntu 11.10 с 3.0.13, у меня не завелось MSI-X на онбордовых 82574L. Возможно, нужно ядро сконфигурить, я с generic тестировал.

Share this post


Link to post
Share on other sites

в догонку - у меня gentoo и ядра собирал руками ванильные

Share this post


Link to post
Share on other sites

По теме - а чем 2.6.32 из RH6 не устраивает?

Ну как минимум тем, что сейчас 2.6.35.14 крутится, с кое-как работающим RSS. А с 37-го ядра таки убрали big kernel lock, что тоже должно прибавить производительности на нагруженных системах.Да и бэкпортить - как-то смысла не вижу.

Share this post


Link to post
Share on other sites

Думаю, больше дело вкуса и желания патчить. В свое время попробовал .35-ое (кое-как там не только RSS) и вернулся на .32-е.

32-е вполне зрелое ядро.

Кстати, не все патчи из RH6 устраивают.

Share this post


Link to post
Share on other sites

Ну меня в целом 35-е ядро устраивает. Но в новых ядрах появилось много интересных плюшек (big kernel lock таки убрали, zram появился - для embedded дистра прекрасная находка, и т.п.), так что перед бета-релизом новой версии дистра ядро буду апдейтить, вопрос только - на какое :)

Судя по чейнджлогу 3.1.4 - вроде как 3.1 ветка уже стабилизировалась (аж один фикс после 3.1.3) :) Так что скорее всего в какую-то альфу его включу. Если 3.2 не выйдет к тому времени.

Edited by NiTr0

Share this post


Link to post
Share on other sites

Кстати говоря в RH6.1 RPS "из коробки" вообще неработоспособно. Не знаю, исправили ли в 6.2.

Кто хочет комисс патчей чтобы заработало, и умеет ядро руками собирать - смотрите в багрепорте: https://bugzilla.redhat.com/show_bug.cgi?id=757040

 

А что не так с RPS в 35 ядре? Я уже давно аккуратно делаю бэкпорты связанных с RPS патчей в центосное (ещё с 5 центоса начиная) ядро, ничего криминального в патчах после 35 не замечал.

 

ЗЫ. Кому надо для компата - пишите в личку, могу подарить центосные исходники ядра 2.6.18 с RPS/RFS, ABI breakage есть, но только по сетевой части.

 

Ну и да, то, что BKL ликвидировали - на сети вряд ли как-то скажется. На брасах ещё RTNL критичен, но если аккуратно подходить к управлению интерфейсами - не сильно влияет.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

А что не так с RPS в 35 ядре?

эдак 1/3 процессорного времени - на ядре, которое принимает прерывания, остальное - примерно равномерно по прочим ядрам распределяется.

Share this post


Link to post
Share on other sites

А поток сильно разнородный? RPS пакеты на процы отправляет по хешу, если пар IP/порт мало - так и должно быть.

Ну и - RPS включен на _всех_ интерфейсах (включая VLAN'ы, bridge'ы и прочие вида ppp) или только на eth? Почему спрашиваю - если изначально это не-IP трафик (PPPoE/PPTP), то поток может быть разбросан по процам только после декапсуляции, и надо RPS включать на ppp-интерфейсах. Если есть бриджи с не-IP трафиком, которые никак не терминируются - RPS тоже ничего не даст.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

Тестировал на PPTP тазике, включение RPS на PPP интерфейсах в добавок к eth (vlan нет) практически ничего не дало по части нагрузки. На PPPoE глубокое тестирование не проводил.

Edited by NiTr0

Share this post


Link to post
Share on other sites

Ну да, Вы правы, дал маху насчёт PPTP - он же поверх IP ходит. Извиняюсь. С PPPoE однозначно будет заметно.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

надо RPS включать на ppp-интерфейсах

Подробнее про эту тему можно, плиз?

Share this post


Link to post
Share on other sites

Я уже давно аккуратно делаю бэкпорты связанных с RPS патчей в центосное

Поделитесь, пожалуйста, для 32-го...

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
Sign in to follow this