Перейти к содержимому
Калькуляторы

uname -a забыли указать

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

disappointed

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

xeb

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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 дней, аж не верится. Если будут эти два валиться и дальше то наверное попробую и на них ядра по-старее поставить, а что делать...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Чёт мне кажется где-то в районе около или после 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.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 валится остальные в панику.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

Изменено пользователем sanyasi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

похоже пришло время начать пилить 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я тестировал с модулем 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

Изменено пользователем sanyasi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Есть в хозяйстве еще один брас, там 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;

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

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

 

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

xeb

пока дело до ALG-ов не дойдет. создал голосовалку http://forum.nag.ru/forum/index.php?showtopic=110563 , потому что сам не особо в них вижу смысл в современных реалиях

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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. И когда был сильный шторм, из-за которого потушились интерфейсы.

 

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.