[Dark_Angel]

Есть два роутера. Оба на линуксе. Один 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.

 

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

Изменено 26 января, 2010 пользователем Dark_Angel

[2c2i]

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

Изменено 26 января, 2010 пользователем 2c2i

[Dark_Angel]

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

 

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

 

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

[2c2i]

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

[Dark_Angel]

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

 

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

Изменено 26 января, 2010 пользователем Dark_Angel

[2c2i]

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

Изменено 26 января, 2010 пользователем 2c2i

[Dark_Angel]

Понимаете, дело не в трафике. Трафика 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

 

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

Изменено 27 января, 2010 пользователем Dark_Angel

[Dark_Angel]

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

 

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