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

Очереди SFQ ведут себя странно

Есть два роутера. Оба на линуксе. Один 2.4.37 - бордер. Второй 2.6.27.38 - BRAS. Трафик как вы понимаете сквозной. На обеих серверах есть шейперы. Шейпятся одинаковым биллингом. Шейпится 200 клиентов.

 

До этого на BRAS было ядро 2.6.20-1 и другая сетевая. Сетевая начала захлебываться по softirq. Поапгрейдили ядро и сетевую после этого на брасе при запросе tc cl sh dev xxx вылазят строки:

 

class sfq 227:3d8 parent 227:

class sfq 227:3e5 parent 227:

class sfq 227:3e6 parent 227:

class sfq 227:3f8 parent 227:

 

И их много. Причем если банально выполнять друг за другом

tc cl sh dev eth0.3 | wc -l

262

tc cl sh dev eth0.3 | wc -l

310

tc cl sh dev eth0.3 | wc -l

308

tc cl sh dev eth0.3 | wc -l

306

 

То есть эти классы постоянно появляются, исчезают. Естественно шейпер такого не делает. Классы шейпера htb и они остаются неизменными. Такое поведение очень сильно грузит систему и фактически стало хуже, чем было с встроеной сетевой. Сейчас стоит 82756EB, настроена на 6 очередей. Если верить mpstat, то ядра грузятся и tx и rx очередями одинаково сильно. Шейперы стоят только на исходящий трафик. На бордере со встроеной сетевой система чувствует себя отлично, там где 82756 загибается. Шейперы на бордере стоят на тех же клиентов, но на исход от бордера.

 

Что может так добавлять и убирать классы и грузить систему? Шейпер использует в качестве очереди для каждого leaf класса SFQ.

 

Если нужна какая-то дополнительная информация - дам, просто может кто-то знает симптомы и узнает проблему. Спасибо.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

Меняющиеся очереди sfq - это нормально. Посмотрите профайлером во что уперлись. В свежих ядрах в tools/perf есть утилитка которой можно удобно глянуть.

Edited by 2c2i

Share this post


Link to post
Share on other sites

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

 

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

 

А почему появилась эта тема с sfq очередями? Есть где-то информация по этому поводу?

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Там по одному фильтру на класс. Фильтры банальные u32 match.

 

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

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

200 клиентов это конечно не много, но попробуйте хештаблицы. Сколько у вас трафика?

Edited by 2c2i

Share this post


Link to post
Share on other sites

Понимаете, дело не в трафике. Трафика 400 Мбит сквозных. Дело в том, что как только шейперы встали - все нормально. Но спустя, скажем сутки или 2-е откуданивозьмись появляется ksoftirqd в топе и начинается какашка. Если шейперы снять - все сразу приходит в норму. И если тут же поставить - тоже все остается в норме. Как Вы понимаете трафик при этом не меняется, количество клиентов тоже. Проблема может наблюдаться на 200-300-400 Мбит сквозняка.

 

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

 

Шейплю просто:

 

tc class add dev INTERFACE parent 1:2 classid 1:ID_CLIENT_IN_SHAPING_TABLE htb rate 1Kbit ceil RATE Kbit

tc qdisc add dev INTERFACE parent 1:ID_CLIENT_IN_SHAPING_TABLE handle ID_CLIENT_IN_SHAPING_TABLE sfq

tc filter add dev INTERFACE parent 1:0 protocol ip prio ID_CLIENT_IN_SHAPING_TABLE u32 match ip dst CLIENT_IP classid 1:ID_CLIENT_IN_SHAPING_TABLE

 

Шейпер со сменой конфигурации не менялся - менялось только ядро, сетевая и настройки сетевой.

Edited by Dark_Angel

Share this post


Link to post
Share on other sites

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

 

Ошибку устранил - понаблюдаю.

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