[GFORGX]

Привет всем!

 

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

 

Есть шейпер на Linux 2.6.32-5, ядро родное Debian, трафик засовывается в разные ifb на основе значения dscp, выставляемого на бордере, классов и фильтров, честно скажу, - дофига:

Core-3.AS51997.net:~# tc class show dev ifb0 | wc -l
7109
Core-3.AS51997.net:~# tc class show dev ifb1 | wc -l
7109

 

Тарифы - 256-1024 Кб/c и 512-2048 Кб/c, 1-4 Мб/c (такого трафика *очень* значительно меньше), классы примерно такого вида:

...
class htb 1:2057 parent 1: prio 0 rate 512000bit ceil 2048Kbit burst 1600b cburst 1599b 
class htb 1:2056 parent 1: prio 0 rate 256000bit ceil 1024Kbit burst 1600b cburst 1599b 
...

 

loadavg выглядит просто чудесно даже в ЧНН при ~600 Мб/c в обе стороны суммарно, добился использованием хэш-таблиц и раскидыванием IRQ сетёвок:

Core-3.AS51997.net:~# w
21:49:58 up  3:09,  2 users,  load average: 0.00, 0.00, 0.00
...

 

Память - 4GB (в реальности 6GB, но пока что не дошли руки поставить -bigmem ядро). Логично, что при таких тарифах и количестве правил высокое использование памяти вполне ожидаемо, но тут происходит нечто несколько странное - объём использованной памяти просто непрерывно растёт (и не уменьшается, по наблюдениям), независимо от нагрузки трафиком, в любое время суток - а потом начинается стрелялка под названием oom-killer. Ничего из сервисов кроме BIRD с FV (оно там некритично и не особо нужно, но, на мой взгляд, особо наличие/отсутствие полной таблицы на нём никакого значения не играет), но он всего 41 МБ потребляет:

BIRD 1.3.1 ready.
bird> show memory 
BIRD memory usage
Routing tables:     26 MB
Route attributes:   14 MB
Protocols:         562 kB
Total:              41 MB

 

Буду благодарен советам, как подебажить использование памяти ядром, и, если у кого-то подобное было, опыту решения проблемы.

Изменено 22 августа, 2011 пользователем GFORGX

[photon]

Откуда такая уверенность в том, что утечки памяти именно из-за HTB? Скорее уж в IFB или BIRD. Надо смотреть расход памяти в top, а не в самом BIRD. Не надо крутить все сервисы на одной машине и усложнять конфигурацию, тогда все будет значительно проще.

Изменено 22 августа, 2011 пользователем photon

[GFORGX]

Откуда такая уверенность в том, что утечки памяти именно из-за HTB? Скорее уж в IFB или BIRD. Надо смотреть расход памяти в top, а не в самом BIRD. Не надо крутить все сервисы на одной машине и усложнять конфигурацию, тогда все будет значительно проще.

Расход памяти в top - нули, отсюда и предположения на ядро. Да, как вариант, возможно, IFB. Никакого усложнения конфигурации и "крутить все сервисы на одной машине" в схеме не вижу, сможете показать, где, - тогда и будете говорить, окей?

Изменено 23 августа, 2011 пользователем GFORGX

[vitalyb]

Если архитектура 32битная - может заканчиваться Low память, ее обычно в районе 800М и если сильно много всего понакручивать и поувеличивать - может и кончится. Смотреть можно /proc/meminfo, slabtop

[GFORGX]

Если архитектура 32битная - может заканчиваться Low память, ее обычно в районе 800М и если сильно много всего понакручивать и поувеличивать - может и кончится. Смотреть можно /proc/meminfo, slabtop

Спасибо, посмотрю. Да, x86.

 

Ещё попробую проверить ifb - в скрипте, который раз в сутки tc -b делает, попробую релоадить модули ifb и act_mirred.

[GFORGX]

Почти вся используемая память в meminfo - в Slab. При попытке slabtop или доступа к /proc/slabinfo получаю ругань:

Core-3.AS51997.net:~# cat /proc/slabinfo 
Killed
Core-3.AS51997.net:~# 
Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.952910] Oops: 0000 [#9] SMP 

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.953043] last sysfs file: /sys/module/thermal/initstate

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.957265] Process cat (pid: 25312, ti=c534e000 task=f657ea40 task.ti=c534e000)

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.957351] Stack:

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.958739] Call Trace:

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.959546] Code: 0e 89 c7 89 d0 f2 ae 74 05 bf 01 00 00 00 4f 89 f8 5f c3 85 c9 57 89 c7 89 d0 74 05 f2 ae 75 01 4f 89 f8 5f c3 89 c1 89 c8 eb 06 <80> 38 00 74 07 40 4a 83 fa ff 75 f4 29 c8 c3 90 55 89 d5 57 56 

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.962039] EIP: [<c113b55c>] strnlen+0x6/0x16 SS:ESP 0068:c534fe48

Message from syslogd@Core-3 at Aug 24 19:25:04 ...
kernel:[175141.962183] CR2: 00000000f8989165

 

На других роутерах и у меня на ноуте чудесно работает... Всё-таки попытаюсь ночью поменять хотя бы версию ядра до того, что в testing.

Изменено 24 августа, 2011 пользователем GFORGX

[GFORGX]

Причина найдена благодаря slabinfo - странное поведение conntrack, пришлось менее вкусно переписать правила на INPUT. Вот только не понятно, почему она проявилась именно в такой комбинации с ifb/htb/ipt_netflow, на апстрим-роутере с тем же ядром conntrack используется в абсолютно аналогичных правилах (на INPUT), жрёт стабильно метров 256 памяти, но не течёт.

Изменено 26 августа, 2011 пользователем GFORGX