[martini]

Делаю маленький эксперимент..

Интересует насущный вопрос - сколько можно использовать правил в разумных пределах ?? чтобы ksoftirqd не жрали весь проц ?

На хеш таблицах сколько правил у кого ? У меня после 1300 правил начинается ужас.. ksoftirqd забирает по 70% на четырех процах.

Сетевые 82576 , процы - 2х2Ггц четырехядерки ксеоны, ядро 3.0, трафика суммарного подавал 1.5 гигабита.

Edited November 22, 2011 by martini

[kayot]

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

[martini]

В соседнем топике у человека тоже огранмчение фильтров сработало, завелось только 2048, дальше ошибки

[kayot]

#nas3 /etc/shaper #tc -s -d filter show dev ifb0 parent 0:0 | grep filte | wc -l

999

#nas3 /etc/shaper #tc -s -d filter show dev eth0.2 parent 0:0 | grep filte | wc -l

4485

В час пик на обоих интефейсах >5к будет, сейчас часть клиентов не шейпится в принципе. Никаких сбоев или роста загрузки нет.

[yannails]

в соседнем топике это у меня:

 

не смог создать более 2048 фильтров на устройство, при этом ограничение не в адресации, а именно по количеству

 

тестировал на:

Centos 5.6 x86_64

Gentoo i686 и x86_64

[martini]

tc qdisc del dev eth1 root handle 1: htb

tc qdisc add dev eth1 root handle 1: htb

 

tc class add dev eth1 parent 1: classid 1:1 htb rate 1gbit ceil 1gbit

tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1500kbit ceil 1500kbit

 

/sbin/tc filter add dev eth1 parent 1:0 protocol ip u32

/sbin/tc filter add dev eth1 parent 1:0 handle 10: protocol ip u32 divisor 256

/sbin/tc filter add dev eth1 parent 1:0 handle 11: protocol ip u32 divisor 256

/sbin/tc filter add dev eth1 parent 1:0 handle 12: protocol ip u32 divisor 256

/sbin/tc filter add dev eth1 parent 1:0 handle 13: protocol ip u32 divisor 256

 

/sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 800:: match ip dst 0.0.0.0/0 hashkey mask 0xff000000 at 16 link 10:

/sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 10:0a: match ip dst 10.0.0.0/8 hashkey mask 0xff0000 at 16 link 11:

/sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 11:1e: match ip dst 10.30.0.0/16 hashkey mask 0xff00 at 16 link 12:

/sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 12:63: match ip dst 10.30.99.0/24 hashkey mask 0xff at 16 link 13:

/sbin/tc filter add dev eth1 parent 1:0 protocol ip u32 ht 13:63: match ip dst 10.30.99.99/32 flowid 1:2

 

Идея с хешами верна ? вроде нигде не ошибся .. но чем больше фильтров становится - тем больше процессора жрет..

[vitalyb]

yannails

Ограничение есть, если правила все проверяются последовательно. 32 битный идентификатор разбивается так 0xaaa:0xbb:0xccc, где (приблизительно, точно не помню) aaa - хендл или номер хештаблицы, bb - индекс в хештаблице, ccc - порядок в последовательности фильтров для данного элемента в хештаблице.

 

martini

такая длинная цепочка не нужна (скорее всего вносит неслабую путаницу и непредсказуемый переход по правилам из-за коллизий идентификаторов). Достаточно "match ip dst 0.0.0.0/0 hashkey mask 0xff at 16" и "match ip dst 10.30.99.99/32" на данной ячейке хештаблицы. При этом этой же ячейкой проверяется и, например, 10.30.98.99, 10.30.100.99, 10.20.99.99 и т.д.

[martini]

хмм.. сделал несколько изменений :

 

tc qdisc del dev eth1 root

tc qdisc add dev eth1 root handle 1: htb

 

tc class add dev eth1 parent 1: classid 1:1 htb rate 1gbit ceil 1gbit

tc class add dev eth1 parent 1:1 classid 1:2 htb rate 1500kbit ceil 1500kbit

 

tc filter add dev eth1 parent 1:0 protocol ip u32

tc filter add dev eth1 parent 1:0 handle 10: protocol ip u32 divisor 256

tc filter add dev eth1 parent 1:0 protocol ip u32 ht 800:: match ip dst 10.30.0.0/16 hashkey mask 0x000000ff at 16 link 10:

tc filter add dev eth1 protocol ip parent 1:0 u32 ht 10:63: match ip dst 10.30.99.99/32 flowid 1:2

 

ситуация не изменилась, загрузка процов прыгает сразу вверх после тыщи фильтров

[yannails]

это оригинальный код шейпера?

ни где не задан r2q или quantum, он тебе не ругаеться в лог quantum of class is big или quantum of class is small?

и я не знаю точно, на сколько это критично но у тебя у корневой дисциплины не создан default class

[martini]

иногда ругается на quantum of class is big и quantum of class is small , какие значения лучше поставить для гигабита ??

дефалт клас создан, я забыл его скопировать. (без него тоже работало)

 

По поводу проблемы количества правил ))) дурдом просто )) - без прио в фильтрах не хочет создавать больше 2048 правил и не работает хеш как надо, как только ставишь прио, все работает идеально.

[Zaqwr]

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

[kayot]

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

А классы работают с помощью волшебства, а не фильтров?

[Alex/AT]

Ещё с HTB на HFSC уйдите, если у вас ядро, конечно, достаточно свежее (в младших ядрах, не помню до какой версии, HFSC может падать вместе с ядром). Это, конечно, проблемы цепочек фильтров из 100500 итемов не решит, но в целом производительность поправит.

[dmitry_]

недавно нумерацию классов на hex числа перевел, т.к. может быть только 4 цифры (0xffff)

 

а по теме, как видно:

tc -s -d filter show dev eth0.38 parent 1:|grep filter|wc -l
10029

ядро 2.6.38.8

нагрузка на сервер 4хIntel® Core™ i5 CPU 760 @ 2.80GHz

top - 23:00:10 up 1 day, 11:10,  1 user,  load average: 0.12, 0.08, 0.06
Tasks:  72 total,   2 running,  70 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 52.3%id,  0.0%wa,  0.0%hi, 47.7%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni, 50.6%id,  0.0%wa,  0.0%hi, 49.4%si,  0.0%st
Cpu2  :  1.1%us,  0.0%sy,  0.0%ni, 53.4%id,  0.0%wa,  0.0%hi, 45.5%si,  0.0%st
Cpu3  :  1.1%us,  0.0%sy,  0.0%ni, 54.0%id,  0.0%wa,  0.0%hi, 44.8%si,  0.0%st

трафика 700М/с

 

у вас tc qdisc созданы на классы?

какие quantum, burst, cburst ставите в классах?

[martini]

shaper172:~/shaper# tc -s -d filter show dev eth1 | grep filter -c

8850

на втором интерфейсе столько же фильтров, трафика бегает 2 гига в сумме, загрузка 1%

top - 22:58:51 up 24 days, 12:12,  1 user,  load average: 0.00, 0.01, 0.05
Tasks:  86 total,   2 running,  83 sleeping,   0 stopped,   1 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

 

кстати, а чем HFSC лучше чем HTB ?

 

И еще вопрос, кто чем шейпит на 10Г интерфейсах ??

[Alex/AT]

Если взглянуть в код - у HFSC меньше сложность операций в цепочках queue / dequeue.

Кроме того, на практике HFSC оказался куда как более предсказуем в плане параметров.

Edited November 24, 2011 by Alex/AT

[GFORGX]

Core-3.AS51997.net:~# tc filter show dev ifb0 | wc -l
14784
Core-3.AS51997.net:~# tc filter show dev ifb1 | wc -l
14784
Core-3.AS51997.net:~# w
04:18:51 up 46 days, 20:04,  1 user,  load average: 0.01, 0.03, 0.00

 

На хэш-фильтрах.

[martini]

так все таки )) как там с 10Г ??? кто то пробовал ? у кого то работает ?

[dmitry_]

так все таки )) как там с 10Г ??? кто то пробовал ? у кого то работает ?

не пробовали, идем по схеме размножения шейперов, и деления нагрузки на каждый

 

а у вас судя по нагрузке должен гиг 5-6 прожевать (на 10Г интерфейсе)

[martini]

2 dmitry_ - исходя из загрузки процов я такую же цифру прикидывал. Завтра добавлю еще 2 гига трафика.

Просто интересна работа tc на интерфейсах 10Г, ато в инете гуляют какие то топики про неточность на 10Г (правда ядра там старые еще)

И еще вопрос - на бондинге tc нормально работает ? или в таком случае лучше на ifb заворачивать и шейпить на нем ?

[shaytan]

shaper172:~/shaper# tc -s -d filter show dev eth1 | grep filter -c

8850

на втором интерфейсе столько же фильтров, трафика бегает 2 гига в сумме, загрузка 1%

top - 22:58:51 up 24 days, 12:12,  1 user,  load average: 0.00, 0.01, 0.05
Tasks:  86 total,   2 running,  83 sleeping,   0 stopped,   1 zombie
Cpu0  :  0.0%us,  0.0%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Cpu4  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.1%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni, 99.9%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st

 

кстати, а чем HFSC лучше чем HTB ?

 

И еще вопрос, кто чем шейпит на 10Г интерфейсах ??

 

nat, netflow в системе задействованы или netfilter вообще отключен в ядре?

[Alex/AT]

И еще вопрос - на бондинге tc нормально работает?

Абсолютно. Правда, я про HFSC, опять же, от HTB отказались как раз в силу непредсказуемости.

[martini]

2 shaytan - да, только шейпер

[GFORGX]

2 shaytan - да, только шейпер

А conntrack не используется?

[martini]

нет, iptables вообще выгружен