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

Какой-то ужас творится с ядрами для серваков в роли BRAS,

Попробовал собрать 4.3.0, машина срубилась в панику через 4 часа работы.

Всё, эксперименты окончены, буду сидеть на 3.2.68 до упора.

Share this post


Link to post
Share on other sites

похоже пришло время начать пилить DPDK/PF_RING...

Share this post


Link to post
Share on other sites

disappointed

4.1.12/13 не пробовали, как вам рекомендовали?

Share this post


Link to post
Share on other sites

xeb

Может быть и рановато.

Я на днях попробую на боевой сервер поставить обновленную сборку, может исчезнет вся загрузка.

Share this post


Link to post
Share on other sites

я к тому что ядра падают

перенести форвардинг пакетов (и не только) в юзерспейс

Share this post


Link to post
Share on other sites

disappointed

4.1.12/13 не пробовали, как вам рекомендовали?

 

Я попробовал :) Вчера на одном брасе собрал 4.1.13, сетевая 82599, драйвера ixgbe 4.2.1 и accel из git. Скоро сутки аптайма, второй сегодня недавно собрал почти такой-же, только ядро решил попробовать 4.2.6. Вот сижу жду кто быстрее кончит :) Есть в хозяйстве еще один брас, там accel 1.9.0 релизный и ядро 3.14.27, там аптайм уже 328 дней, аж не верится. Если будут эти два валиться и дальше то наверное попробую и на них ядра по-старее поставить, а что делать...

Share this post


Link to post
Share on other sites

Чёт мне кажется где-то в районе около или после 3.14 сломали нечто

и форкают эту дрянь по текущее ядро.

Есть в хозяйстве еще один брас, там accel 1.9.0 релизный и ядро 3.14.27, там аптайм уже 328 дней, аж не верится. Если будут эти два валиться и дальше то наверное попробую и на них ядра по-старее поставить, а что делать...

А если 3.14.57 собрать для теста?

4.1.13 - попозже проверю, на днях.

Share this post


Link to post
Share on other sites

Чёт мне кажется где-то в районе около или после 3.14 сломали нечто

и форкают эту дрянь по текущее ядро.

Есть в хозяйстве еще один брас, там accel 1.9.0 релизный и ядро 3.14.27, там аптайм уже 328 дней, аж не верится. Если будут эти два валиться и дальше то наверное попробую и на них ядра по-старее поставить, а что делать...

А если 3.14.57 собрать для теста?

 

Я тоже к этому склоняюсь. Если еще раз один из брасов на новых ядрах повиснет то обязательно соберу 3.14.

Share this post


Link to post
Share on other sites

Чёт мне кажется где-то в районе около или после 3.14 сломали нечто

и форкают эту дрянь по текущее ядро.

Речь идёт о ванильном ядре, или о ядре в котором поковырялись debian, centos и т.п?

У меня на ванильном ядре, все прекрасно.

Linux 3.15.3 #1 SMP Wed Jul 2 23:44:49 EEST 2014 x86_64 Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz GenuineIntel GNU/Linux

Share this post


Link to post
Share on other sites

Чёт мне кажется где-то в районе около или после 3.14 сломали нечто

и форкают эту дрянь по текущее ядро.

Речь идёт о ванильном ядре, или о ядре в котором поковырялись debian, centos и т.п?

У меня на ванильном ядре, все прекрасно.

Linux 3.15.3 #1 SMP Wed Jul 2 23:44:49 EEST 2014 x86_64 Intel(R) Xeon(R) CPU E5-2650 0 @ 2.00GHz GenuineIntel GNU/Linux

3.16.7 и 4.2.6 - дебиановские пробовал, 4.3.0 - ванильное собирал вчера,

первое в oops валится остальные в панику.

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

похоже пришло время начать пилить DPDK/PF_RING...

Как мне кажется давно пора, а то искать золотое сечение между ядрами и релизами accel - только Евклиду посильно

Share this post


Link to post
Share on other sites

Есть в хозяйстве еще один брас, там accel 1.9.0 релизный и ядро 3.14.27, там аптайм уже 328 дней, аж не верится.

3.14 ЕМНИП у меня падало, при удалении шейпера с downed ифейса. после чего и ушел на 4.1... не особо тогда помогло.

Share this post


Link to post
Share on other sites

Мне кажется что бессмысленно это ковыряние между ядрами. Если между мажорными релизами паника осталась - значит беда где-то в консерватории.

А кто готов ставить дебуг ядро и ковырять полные дампы на боевых серверах?

Share this post


Link to post
Share on other sites

полные дампы на боевых серверах?

 

Зачем на боевых. Надо просто соорудить тест виртуалку, и готовый набор генераторов соединений, и пакетов. Паника возникает при подключении/отключении ppp интерфейса, и возможно связана с удалением из последних ядер глобальных блокировок.

Возможно, ее можно даже без трафика поймать. Тут в теме уже есть много дампов.

Edited by sanyasi

Share this post


Link to post
Share on other sites

похоже пришло время начать пилить DPDK/PF_RING...

 

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

 

вообще, надо просто сделать нормальный багрепорт в netdev@ или в netfilter. Судя по сообщениям выше, проблема где-то около conntrack в момент создания/удаления интерфейсов, как и говорит предыдущий оратор

 

возможно, в правилах iptables что-то типа iptables -t nat -I POSTROUNT -i ppp+ .... (и проблемы с этим ppp+). выкладывайте правила iptables, у кого падает

 

У кого интерфейсов меньше 1-2К, можно брать 3.2.последнее ядро с kernel.org и работать на нём. чтоб быстро подключались абоненты, установить unit-cache=2000 в accel

 

Есть в хозяйстве еще один брас, там accel 1.9.0 релизный и ядро 3.14.27, там аптайм уже 328 дней, аж не верится.

3.14 ЕМНИП у меня падало, при удалении шейпера с downed ифейса. после чего и ушел на 4.1... не особо тогда помогло.

 

шейпер скриптом или accel-ем? если шейпер accel-ем навешивается, то всё ок на 3.14

Share this post


Link to post
Share on other sites

я тестировал с модулем ipt_ratelimit без навешивания шейпера на интерфейсы. Падало на ядрах 3.13. 3.16 3.19 4.2.

Думали на модуль ipt_ratelimit.

Гит + дамп паники

 

Но вернувшись на 3.2 падения прекратились. Шейпер не при чем. Нат да, вызывает подозрения, но как генератор дополнительной нагрузки на систему.

 

На счет ppp+ во время падений на новых ядрах использовалось без ppp+.

 

-A POSTROUTING -s 172.16.0.0/16 -j SNAT --to-source 1.2.3.1-1.2.4.254 --persistent

Edited by sanyasi

Share this post


Link to post
Share on other sites

полные дампы на боевых серверах?

 

Зачем на боевых. Надо просто соорудить тест виртуалку, и готовый набор генераторов соединений, и пакетов. Паника возникает при подключении/отключении ppp интерфейса, и возможно связана с удалением из последних ядер глобальных блокировок.

Возможно, ее можно даже без трафика поймать. Тут в теме уже есть много дампов.

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

Share this post


Link to post
Share on other sites

Есть в хозяйстве еще один брас, там accel 1.9.0 релизный и ядро 3.14.27, там аптайм уже 328 дней, аж не верится.

3.14 ЕМНИП у меня падало, при удалении шейпера с downed ифейса. после чего и ушел на 4.1... не особо тогда помогло.

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

diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c

index cb5d4ad32946..7f5f3e8a10f5 100644

--- a/net/sched/sch_generic.c

+++ b/net/sched/sch_generic.c

@@ -706,9 +706,11 @@ struct Qdisc *dev_graft_qdisc(struct netdev_queue *dev_queue,

spin_lock_bh(root_lock);

 

/* Prune old scheduler */

- if (oqdisc && atomic_read(&oqdisc->refcnt) <= 1)

- qdisc_reset(oqdisc);

-

+ if (oqdisc) {

+ if (atomic_read(&oqdisc->refcnt) <= 1)

+ qdisc_reset(oqdisc);

+ set_bit(__QDISC_STATE_DEACTIVATED, &oqdisc->state);

+ }

/* ... and graft new one */

if (qdisc == NULL)

qdisc = &noop_qdisc;

Share this post


Link to post
Share on other sites
это конечно прикольно, но тут объем работ в разы или в десятки раз больше, чем обработка сигнализации
если не закладываться сразу такими сложными вещами как iptables и сложные схемы маршрутизации, а ограничиться простой маршрутизацией и шейпер, то как мне видится задача вполне подъёмная

Share this post


Link to post
Share on other sites
это конечно прикольно, но тут объем работ в разы или в десятки раз больше, чем обработка сигнализации
если не закладываться сразу такими сложными вещами как iptables и сложные схемы маршрутизации, а ограничиться простой маршрутизацией и шейпер, то как мне видится задача вполне подъёмная

 

у многих bras+nat это одна коробка. конечно, сервер стоит не миллионы, чтобы nat и прочее вынести, но всё же это резко ограничит применимость

ну или шейперы/полисеры извращённые(скриптами навешивают), что тоже усложняет задачу

 

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

 

сейчас по производительности, ядро linux очень неплохое(для практических задач <10G вообще отлично справляется), просто нужно пофиксить 1-2 бага и всё станет хорошо

Share this post


Link to post
Share on other sites

нат сделать тоже не проблема

ну а с извращениями тогда через ядро

Share this post


Link to post
Share on other sites

Коллеги внесу свои пять копеек.

 

Linux pppoe18 3.16.0-41-generic #57~14.04.1-Ubuntu SMP Thu Jun 18 18:01:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

 

1.9 accel-ppp version b8b91d8b087312c91a9941dacd11a98692679ec8

 

Около 1к абонентов. + нат. + bonding

 

 

Падало два раза, когда ребутил 3750. И когда был сильный шторм, из-за которого потушились интерфейсы.

 

 

Вот именно, когда интерфейсы шутятся тогда все и падает.

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