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

htb, использование памяти

Привет всем!

 

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

 

Есть шейпер на 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

 

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

Edited by GFORGX

Share this post


Link to post
Share on other sites

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

Edited by photon

Share this post


Link to post
Share on other sites

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

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

Edited by GFORGX

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


Link to post
Share on other sites

Почти вся используемая память в 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.

Edited by GFORGX

Share this post


Link to post
Share on other sites

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

Edited by GFORGX

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