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

Злобный шейпер tc, htb - лаги на машине с 1200+ правилами

Всем привет!

 

Есть набор правил tc, в количестве почти 1000+ штук - машина работает шейпером для большого числа "клиентов" (VPS). К машине подведен 1 гигабит линка. Клиентам выдается по 20-50 мегабит каждому. Реального же на машине более 100 мегабит не бывает в принципе.

 

Проблема заключается в том, что при включении шейпера очень сильно проваливается скорость на самой машине (замеры через iperf через почти не загруженный гигабитный линк):

[  4]  0.0-10.0 sec   227 MBytes   190 Mbits/sec
[  5]  0.0-10.3 sec   297 MBytes   242 Mbits/sec
[  4]  0.0-10.0 sec   508 MBytes   426 Mbits/sec

Если шейпер отключить (вообще), она мгновенно взлетает:

[  4]  0.0-10.0 sec  1.05 GBytes   900 Mbits/sec
[  5]  0.0-10.0 sec  1.04 GBytes   889 Mbits/sec
[  4]  0.0-10.0 sec  1.04 GBytes   889 Mbits/sec

Также у клиентов начинается непонятная свистопляска со скоростью - она вовсе не 20-30 мегабит, а иногда падает до нескольких сотен килобит.

Правила навешиваются скриптом, но делает он следующее.

Удаляем правила

/sbin/tc qdisc del dev venet0 root
/sbin/tc qdisc del dev bond0 root

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

/sbin/tc qdisc add dev venet0 root handle 1: htb default 0 r2q 3000

Создаем корневые htb

/sbin/tc class add dev venet0 parent 1: classid 1:1 htb rate 1000mbit burst 100k
/sbin/tc qdisc add dev bond0 root handle 1: htb default 0 r2q 3000
/sbin/tc class add dev bond0 parent 1: classid 1:1 htb rate 1000mbit burst 100k

Создаем класс на 20 мегабит на клиента (лимитируется в нем и IPv4 и IPv6 трафик) - и вешаем их на два интерфейса - eth0 и venet0 (виртализированный), вешаются на оба, чтобы нормально лимитировать трафик в обоих направлениях:

/sbin/tc class add dev venet0 parent 1:1 classid 1:a htb rate 20000kbit ceil 20000kbit burst 100k quantum 2500
/sbin/tc qdisc add dev venet0 parent 1:a handle a: sfq perturb 10
/sbin/tc class add dev bond0 parent 1:1 classid 1:a htb rate 20000kbit ceil 20000kbit burst 100k quantum 2500
/sbin/tc qdisc add dev bond0 parent 1:a handle a: sfq perturb 10

Вешаем фильтры на входящий/исходящий IPv4 трафик

/sbin/tc filter add dev venet0 handle 800::1 protocol ip parent 1: prio 1 u32 match ip dst "46.36.218.60" flowid 1:10
/sbin/tc filter add dev bond0 handle 800::2 protocol ip parent 1: prio 1 u32 match ip src "46.36.218.60" flowid 1:10

Вешаем фильтры на входящий/исходящий IPv6 трафик

/sbin/tc filter add dev venet0 handle 801::3 protocol ipv6 parent 1: prio 2 u32 match ip6 dst "2a03:f480:1:13::29" flowid 1:10
/sbin/tc filter add dev bond0 handle 801::4 protocol ipv6 parent 1: prio 2 u32 match ip6 src "2a03:f480:1:13::29" flowid 1:10

Ну и для остальных клиентов по аналогии:

/sbin/tc class add dev venet0 parent 1:1 classid 1:14 htb rate 20000kbit ceil 20000kbit burst 100k quantum 2500
/sbin/tc qdisc add dev venet0 parent 1:14 handle 14: sfq perturb 10
/sbin/tc class add dev bond0 parent 1:1 classid 1:14 htb rate 20000kbit ceil 20000kbit burst 100k quantum 2500
/sbin/tc qdisc add dev bond0 parent 1:14 handle 14: sfq perturb 10
/sbin/tc filter add dev venet0 handle 800::5 protocol ip parent 1: prio 1 u32 match ip dst "46.36.218.111" flowid 1:20
/sbin/tc filter add dev bond0 handle 800::6 protocol ip parent 1: prio 1 u32 match ip src "46.36.218.111" flowid 1:20
/sbin/tc filter add dev venet0 handle 801::7 protocol ipv6 parent 1: prio 2 u32 match ip6 dst "2a03:f480:1:13::2e" flowid 1:20
/sbin/tc filter add dev bond0 handle 801::8 protocol ipv6 parent 1: prio 2 u32 match ip6 src "2a03:f480:1:13::2e" flowid 1:20
/sbin/tc class add dev venet0 parent 1:1 classid 1:1e htb rate 20000kbit ceil 20000kbit burst 100k quantum 2500
/sbin/tc qdisc add dev venet0 parent 1:1e handle 1e: sfq perturb 10
/sbin/tc class add dev bond0 parent 1:1 classid 1:1e htb rate 20000kbit ceil 20000kbit burst 100k quantum 2500
/sbin/tc qdisc add dev bond0 parent 1:1e handle 1e: sfq perturb 10
/sbin/tc filter add dev venet0 handle 800::9 protocol ip parent 1: prio 1 u32 match ip dst "5.45.124.242" flowid 1:30
/sbin/tc filter add dev bond0 handle 800::a protocol ip parent 1: prio 1 u32 match ip src "5.45.124.242" flowid 1:30
/sbin/tc filter add dev venet0 handle 801::b protocol ipv6 parent 1: prio 2 u32 match ip6 dst "2a03:f480:1:13::91" flowid 1:30
/sbin/tc filter add dev bond0 handle 801::c protocol ipv6 parent 1: prio 2 u32 match ip6 src "2a03:f480:1:13::91" flowid 1:30
...
тут еще тысяча с лишним строк

 

В perf top при этом:

12,90%  [kernel]             [k] read_hpet
 6,70%  [kernel]             [k] copy_user_enhanced_fast_string
 3,00%  [kernel]             [k] _spin_lock
 2,53%  [kernel]             [k] __d_lookup
 1,87%  [kernel]             [k] find_get_page
 1,84%  [kernel]             [k] __link_path_walk
 1,52%  [kernel]             [k] _atomic_dec_and_lock
 1,41%  [kernel]             [k] fget_light
 1,37%  [kernel]             [k] kmem_cache_free
 1,34%  [kernel]             [k] __audit_syscall_exit
 1,23%  [kernel]             [k] kmem_cache_alloc
 0,98%  [kernel]             [k] page_fault
 0,97%  [kernel]             [k] acl_permission_check
 0,92%  [kernel]             [k] clear_page_c_e
 0,90%  [kernel]             [k] ub_file_charge
 0,89%  [kernel]             [k] radix_tree_lookup_slot
 0,75%  [kernel]             [k] audit_syscall_entry
 0,73%  [kernel]             [k] find_busiest_group
 0,71%  [kernel]             [k] memset
 0,68%  [kernel]             [k] list_del
 0,66%  [kernel]             [k] _cond_resched
 0,62%  [kernel]             [k] generic_file_read_iter
 0,57%  [kernel]             [k] dput_nocache
 0,56%  [kernel]             [k] copy_user_generic_string
 0,55%  [kernel]             [k] established_get_next
 0,53%  [kernel]             [k] schedule
 0,52%  [kernel]             [k] precharge_beancounter
 0,50%  [kernel]             [k] unmap_vmas
 0,50%  [kernel]             [k] __alloc_pages_nodemask

 

Куда дальше рыть - я не знаю. Проставляюсь обедом с алкоголем в Питере в случае успешного фикса =)

 

Платформа CentOS 6 + 2.6.32 стандартное ядро, изменить/обновить - невозможно.

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

Смотреть в сторону хэшей в filter. На i3 спокойно пережевывается 2 гигабита при ~2 тыс правил на интерфейс

Share this post


Link to post
Share on other sites

Хэшей?

 

Проблема в том, что на машине куча процессорного времени свободно, перегрузку по system/interrupts нету. Да и классификатор не светится в perf top.

 

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

Samples: 18M of event 'cycles', Event count (approx.): 221890255174
 9,19%  [cls_u32]            [k] u32_classify
 8,96%  [kernel]             [k] _spin_lock
 4,15%  [kernel]             [k] read_hpet
 4,03%  [kernel]             [k] copy_user_enhanced_fast_string
 3,15%  [kernel]             [k] __d_lookup
 2,34%  [kernel]             [k] __link_path_walk
 1,97%  [kernel]             [k] fget_light
 1,48%  [kernel]             [k] __audit_syscall_exit
 1,46%  [kernel]             [k] _atomic_dec_and_lock
 1,39%  [kernel]             [k] acl_permission_check
 1,39%  [kernel]             [k] generic_file_read_iter
 1,30%  [kernel]             [k] find_get_page
 1,27%  [kernel]             [k] vfs_read
 1,25%  [kernel]             [k] radix_tree_lookup_slot
 1,05%  [kernel]             [k] touch_atime
 0,96%  [kernel]             [k] clear_page_c_e
 0,96%  [kernel]             [k] kmem_cache_free
 0,95%  [kernel]             [k] page_fault
 0,94%  [kernel]             [k] audit_syscall_entry
 0,87%  [kernel]             [k] in_group_p
 0,86%  [kernel]             [k] unmap_vmas
 0,75%  [kernel]             [k] kmem_cache_alloc
 0,66%  [kernel]             [k] precharge_beancounter
 0,63%  [kernel]             [k] system_call_after_swapgs
 0,59%  [kernel]             [k] dput_nocache
 0,58%  [kernel]             [k] follow_managed

 

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

 

На всякий случай привожу выдержку из top:

Cpu(s): 17.5%us,  9.9%sy,  1.0%ni, 68.4%id,  2.7%wa,  0.0%hi,  0.6%si,  0.0%st

 

Clocksource: hpet

Share this post


Link to post
Share on other sites

Хэши же позволят произвести классификацию пакета в 2-3 шага при любом количестве записей в списке. В вашем же случае, чем больше элементов в списке, тем больший путь по фильтрам должен будет пройти пакет до того, как попадет на свой фильтр. И самому неудачному прижется прошерститься по всем элементам списка. И так для каждого пакета.

 

Аналогичная проблема позникает и с iptables, когда пытаются затолкнуть линейно тысячи записей.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Всем спасибо за ответы!

 

Немного хочу уточнить свои вопросы.

 

adnull, а как это схождение с ума объяснить технически? Сейчас попробую, в принципе, хуже явно не станет.

 

Вот у меня используется такое правило:

/sbin/tc qdisc add dev venet0 root handle 1: htb default 0 r2q 3000

 

Судя по официальной документации (An optional parameter with every HTB qdisc object, the default default is 0, which cause any unclassified traffic to be dequeued at hardware speed, completely bypassing any of the classes attached to the root qdisc.), оно должно отключить полностью все дисциплины шейпинга, если трафик не попал ни под один фильтр (случай трафика самого роутера).

 

Также не понятно с фильтрами, если бы проблема была в них, то я бы видел проблемы в top (перегрузка по system) либо в perf, но классификатор ни там, ни там не светится же :(

Share this post


Link to post
Share on other sites

Попробовал рекомендацию adnull'а - изменил суммарный rate родительского класса с 1000 мегабит на сумму rate всех дочерних классов:

class htb 1:1 root rate 11320Mbit ceil 11320Mbit burst 101880b cburst 0b 

 

Снял с нескольких машин perf top и в общем-то да, u32_classify много где светится.

 

#9

Samples: 11M of event 'cycles', Event count (approx.): 244827857152
 8,63%  [kernel]             [k] copy_user_enhanced_fast_string
 3,14%  [cls_u32]            [k] u32_classify
 2,72%  [kernel]             [k] _spin_lock
 2,47%  [kernel]             [k] find_get_page
 1,91%  [kernel]             [k] update_curr
 1,90%  [kernel]             [k] __d_lookup
 1,76%  [kernel]             [k] fget_light
 1,56%  [kernel]             [k] futex_wake
 1,47%  [kernel]             [k] radix_tree_lookup_slot
 1,47%  [kernel]             [k] __audit_syscall_exit
 1,41%  [kernel]             [k] __link_path_walk
 1,39%  [twofish_common]     [k] twofish_setkey

#10:

Samples: 136M of event 'cycles', Event count (approx.): 202052440889
13,33%  [kernel]             [k] read_hpet
 5,29%  [kernel]             [k] copy_user_enhanced_fast_string
 2,99%  [kernel]             [k] _spin_lock
 2,29%  [cls_u32]            [k] u32_classify
 2,04%  [kernel]             [k] __d_lookup
 1,60%  [kernel]             [k] fget_light
 1,45%  [kernel]             [k] __link_path_walk
 1,45%  [kernel]             [k] find_get_page
 1,36%  [ext4]               [k] ext4_htree_store_dirent
 1,33%  [kernel]             [k] _atomic_dec_and_lock

#11:

amples: 65M of event 'cycles', Event count (approx.): 192959339108
 5,73%  [kernel]             [k] copy_user_enhanced_fast_string                                                                                   ◆
 3,46%  [cls_u32]            [k] u32_classify                                                                                                     ▒
 3,31%  [bluetooth]          [k] 0x0000000000020606                                                                                               ▒
 2,88%  [kernel]             [k] _spin_lock                                                                                                       ▒
 2,05%  [kernel]             [k] __d_lookup                                                                                                       ▒
 1,92%  [kernel]             [k] copy_user_generic_string                                                                                         ▒
 1,65%  [kernel]             [k] __audit_syscall_exit                                                                                             ▒
 1,60%  [kernel]             [k] fget_light                                                                                                       ▒
 1,42%  [kernel]             [k] __link_path_walk                                                                                                 ▒
 1,40%  [kernel]             [k] find_get_page                                   

 

Буду пробовать переписать классификатор на хэши.

Share this post


Link to post
Share on other sites

Превышение суммы rate всех классов над скоростью корневого класса, иначе говоря, oversubscription -- это нормальная ситуация для провайдера, так же как и для банка, который выдает кредитов больше, чем у него есть наличных денег. Главное -- с помощью Nagios/Cacti/Zabbix или чего-то еще измерять суммарную полосу, которую реально загружают пользователи и следить за тем, чтобы она не упиралась в полку, иначе начнутся потери пакетов. Генерация правил с хэш-фильтрами уже давно автоматизирована: http://sourceforge.net/projects/sc-tool/

Edited by photon

Share this post


Link to post
Share on other sites

Мистика, блин. Дошло до абсурда, убрал вообще все правила. Оставил одного клиента, который вот прямо сейчас ест 500 мегабит из 50 дозволенных.

 

Наложил лишь один раз все правила:

Starting to execute command: /sbin/tc qdisc del dev venet0 root
Starting to execute command: /sbin/tc qdisc del dev bond0 root
Starting to execute command: /sbin/tc qdisc add dev venet0 root handle 1: htb default 0 r2q 3000
Starting to execute command: /sbin/tc class add dev venet0 parent 1: classid 1:1 htb rate 50000kbit burst 100k
Starting to execute command: /sbin/tc qdisc add dev bond0 root handle 1: htb default 0 r2q 3000
Starting to execute command: /sbin/tc class add dev bond0 parent 1: classid 1:1 htb rate 50000kbit burst 100k
Starting to execute command: /sbin/tc class add dev venet0 parent 1:1 classid 1:a htb rate 50000kbit ceil 50000kbit burst 100k quantum 2500
Starting to execute command: /sbin/tc qdisc add dev venet0 parent 1:a handle a: sfq perturb 10
Starting to execute command: /sbin/tc class add dev bond0 parent 1:1 classid 1:a htb rate 50000kbit ceil 50000kbit burst 100k quantum 2500
Starting to execute command: /sbin/tc qdisc add dev bond0 parent 1:a handle a: sfq perturb 10
Starting to execute command: /sbin/tc filter add dev venet0 handle 800::1 protocol ip parent 1: prio 1 u32 match ip dst "46.36.221.114" flowid 1:10
Starting to execute command: /sbin/tc filter add dev bond0 handle 800::2 protocol ip parent 1: prio 1 u32 match ip src "46.36.221.114" flowid 1:10
Starting to execute command: /sbin/tc filter add dev venet0 handle 801::3 protocol ipv6 parent 1: prio 2 u32 match ip6 dst "2a03:f480:1:5::d9" flowid 1:10
Starting to execute command: /sbin/tc filter add dev bond0 handle 801::4 protocol ipv6 parent 1: prio 2 u32 match ip6 src "2a03:f480:1:5::d9" flowid 1:10

 

Но с клиента как лилось 500 мегабит исходящего, так и льется:

     venet0      
Kbps in  Kbps out
11057.28  474938.2
11098.53  454684.6
13708.36  536709.8
12899.55  524383.8
11256.32  451945.3
11436.45  436171.0
10666.75  435321.5
11853.04  449605.4
11588.72  432400.8

 

Фильтры работают:

 

tc -s filter show dev bond0
filter parent 1: protocol ip pref 1 u32 
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 1 u32 fh 800::2 order 2 key ht 800 bkt 0 flowid 1:10  (rule hit 5514593 success 5001665)
 match 2e24dd72/ffffffff at 12 (success 5001665 ) 
filter parent 1: protocol ipv6 pref 2 u32 
filter parent 1: protocol ipv6 pref 2 u32 fh 801: ht divisor 1 
filter parent 1: protocol ipv6 pref 2 u32 fh 801::4 order 4 key ht 801 bkt 0 flowid 1:10  (rule hit 271 success 0)
 match 2a03f480/ffffffff at 8 (success 249 ) 
 match 00010005/ffffffff at 12 (success 0 ) 
 match 00000000/ffffffff at 16 (success 0 ) 
 match 000000d9/ffffffff at 20 (success 0 ) 


tc -s filter show dev venet0
filter parent 1: protocol ip pref 1 u32 
filter parent 1: protocol ip pref 1 u32 fh 800: ht divisor 1 
filter parent 1: protocol ip pref 1 u32 fh 800::1 order 1 key ht 800 bkt 0 flowid 1:10  (rule hit 3749971 success 3355967)
 match 2e24dd72/ffffffff at 16 (success 3355967 ) 
filter parent 1: protocol ipv6 pref 2 u32 
filter parent 1: protocol ipv6 pref 2 u32 fh 801: ht divisor 1 
filter parent 1: protocol ipv6 pref 2 u32 fh 801::3 order 3 key ht 801 bkt 0 flowid 1:10  (rule hit 224 success 0)
 match 2a03f480/ffffffff at 24 (success 224 ) 
 match 00010005/ffffffff at 28 (success 0 ) 
 match 00000000/ffffffff at 32 (success 0 ) 
 match 000000d9/ffffffff at 36 (success 0 ) 

 

Классы тоже в норме:

tc -s class show dev venet0
class htb 1:1 root rate 50000Kbit ceil 50000Kbit burst 100Kb cburst 1600b 
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
lended: 0 borrowed: 0 giants: 0
tokens: 256000 ctokens: 4000

class htb 1:a parent 1:1 leaf a: prio 0 rate 50000Kbit ceil 50000Kbit burst 100Kb cburst 1600b 
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
lended: 0 borrowed: 0 giants: 0
tokens: 256000 ctokens: 4000

tc -s class show dev bond0
class htb 1:1 root rate 50000Kbit ceil 50000Kbit burst 100Kb cburst 1600b 
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
lended: 0 borrowed: 0 giants: 0
tokens: 256000 ctokens: 4000

class htb 1:a parent 1:1 leaf a: prio 0 rate 50000Kbit ceil 50000Kbit burst 100Kb cburst 1600b 
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
lended: 0 borrowed: 0 giants: 0
tokens: 256000 ctokens: 4000

 

Qdisc'и:

tc qdisc show
qdisc mq 0: dev em1 root 
qdisc mq 0: dev em2 root 
qdisc htb 1: dev bond0 root refcnt 17 r2q 3000 default 0 direct_packets_stat 21290023
qdisc sfq a: dev bond0 parent 1:a limit 127p quantum 1514b perturb 10sec 
qdisc htb 1: dev venet0 root refcnt 2 r2q 3000 default 0 direct_packets_stat 13236369
qdisc sfq a: dev venet0 parent 1:a limit 127p quantum 1514b perturb 10sec 

 

Я с ума сойду с этим tc :(

 

Были подозрения, что виноват bonding, дошел до абсурда, навесил правила на составляющие его интерфейсы - безрезультатно.

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

Оба включены :(

 

Пробую отключить:

ethtool -k em1
Features for em1:
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp-segmentation-offload: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off
ntuple-filters: off
receive-hashing: off

 

gso/gro вырубил:

ethtool -K em1 gso off gro off
ethtool -K em2 gso off gro off

 

Но результата, увы, нет :(

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

Мистика, блин. Дошло до абсурда, убрал вообще все правила. Оставил одного клиента, который вот прямо сейчас ест 500 мегабит из 50 дозволенных.

 

Наложил лишь один раз все правила:

Starting to execute command: /sbin/tc qdisc del dev venet0 root
Starting to execute command: /sbin/tc qdisc del dev bond0 root
Starting to execute command: /sbin/tc qdisc add dev venet0 root handle 1: htb default 0 r2q 3000
Starting to execute command: /sbin/tc class add dev venet0 parent 1: classid 1:1 htb rate 50000kbit burst 100k
Starting to execute command: /sbin/tc qdisc add dev bond0 root handle 1: htb default 0 r2q 3000
Starting to execute command: /sbin/tc class add dev bond0 parent 1: classid 1:1 htb rate 50000kbit burst 100k
Starting to execute command: /sbin/tc class add dev venet0 parent 1:1 classid 1:a htb rate 50000kbit ceil 50000kbit burst 100k quantum 2500
Starting to execute command: /sbin/tc qdisc add dev venet0 parent 1:a handle a: sfq perturb 10
Starting to execute command: /sbin/tc class add dev bond0 parent 1:1 classid 1:a htb rate 50000kbit ceil 50000kbit burst 100k quantum 2500
Starting to execute command: /sbin/tc qdisc add dev bond0 parent 1:a handle a: sfq perturb 10
Starting to execute command: /sbin/tc filter add dev venet0 handle 800::1 protocol ip parent 1: prio 1 u32 match ip dst "46.36.221.114" flowid 1:10
Starting to execute command: /sbin/tc filter add dev bond0 handle 800::2 protocol ip parent 1: prio 1 u32 match ip src "46.36.221.114" flowid 1:10
Starting to execute command: /sbin/tc filter add dev venet0 handle 801::3 protocol ipv6 parent 1: prio 2 u32 match ip6 dst "2a03:f480:1:5::d9" flowid 1:10
Starting to execute command: /sbin/tc filter add dev bond0 handle 801::4 protocol ipv6 parent 1: prio 2 u32 match ip6 src "2a03:f480:1:5::d9" flowid 1:10

 

Но с клиента как лилось 500 мегабит исходящего, так и льется:

Собственно, у меня 1 вопрос.

Почему вы класс создаете с classid 1:a, а в фильтре трафик наливаете в несуществующий flowid 1:10? Везде в смещениях/номерах классов должен быть hex, данная конструкция работать не может.

Edited by kayot

Share this post


Link to post
Share on other sites

Мистика, блин. Дошло до абсурда, убрал вообще все правила. Оставил одного клиента, который вот прямо сейчас ест 500 мегабит из 50 дозволенных.

 

Наложил лишь один раз все правила:

Starting to execute command: /sbin/tc qdisc del dev venet0 root
Starting to execute command: /sbin/tc qdisc del dev bond0 root
Starting to execute command: /sbin/tc qdisc add dev venet0 root handle 1: htb default 0 r2q 3000
Starting to execute command: /sbin/tc class add dev venet0 parent 1: classid 1:1 htb rate 50000kbit burst 100k
Starting to execute command: /sbin/tc qdisc add dev bond0 root handle 1: htb default 0 r2q 3000
Starting to execute command: /sbin/tc class add dev bond0 parent 1: classid 1:1 htb rate 50000kbit burst 100k
Starting to execute command: /sbin/tc class add dev venet0 parent 1:1 classid 1:a htb rate 50000kbit ceil 50000kbit burst 100k quantum 2500
Starting to execute command: /sbin/tc qdisc add dev venet0 parent 1:a handle a: sfq perturb 10
Starting to execute command: /sbin/tc class add dev bond0 parent 1:1 classid 1:a htb rate 50000kbit ceil 50000kbit burst 100k quantum 2500
Starting to execute command: /sbin/tc qdisc add dev bond0 parent 1:a handle a: sfq perturb 10
Starting to execute command: /sbin/tc filter add dev venet0 handle 800::1 protocol ip parent 1: prio 1 u32 match ip dst "46.36.221.114" flowid 1:10
Starting to execute command: /sbin/tc filter add dev bond0 handle 800::2 protocol ip parent 1: prio 1 u32 match ip src "46.36.221.114" flowid 1:10
Starting to execute command: /sbin/tc filter add dev venet0 handle 801::3 protocol ipv6 parent 1: prio 2 u32 match ip6 dst "2a03:f480:1:5::d9" flowid 1:10
Starting to execute command: /sbin/tc filter add dev bond0 handle 801::4 protocol ipv6 parent 1: prio 2 u32 match ip6 src "2a03:f480:1:5::d9" flowid 1:10

 

Но с клиента как лилось 500 мегабит исходящего, так и льется:

Собственно, у меня 1 вопрос.

Почему вы класс создаете с classid 1:a, а в фильтре трафик наливаете в несуществующий flowid 1:10? Везде в смещениях/номерах классов должен быть hex, данная конструкция работать не может.

 

Вместо тысячи слов картинка графики! Вы волшебник, огромное спасибо! :)

Edited by pavel.odintsov

Share this post


Link to post
Share on other sites

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

С чего бы ему с ума сходить?

 

По сабжу:

1) Отключить все оффлоады кроме контрольных сумм и scatter-gather - т.е. tso/gso/gro/lro;

2) Посмотреть, чего clock source - HPET, а не TSC.

Share this post


Link to post
Share on other sites

Всем спасибо еще раз :)

 

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

 

Тут благодарности к taf_321, хэш просто творит чудеса.

 

С линейными правилами perf top:

Samples: 4M of event 'cycles', Event count (approx.): 238953242335
 11,80%  [kernel]             [k] read_hpet
 3,78%  [kernel]             [k] _spin_lock
 3,03%  [cls_u32]            [k] u32_classify
 2,60%  [kernel]             [k] __d_lookup

 

На хэшах:

Samples: 40M of event 'cycles', Event count (approx.): 200369370951
15,24%  [kernel]             [k] read_hpet
 3,69%  [kernel]             [k] _spin_lock
 3,05%  [kernel]             [k] __d_lookup
 2,58%  [kernel]             [k] copy_user_enhanced_fast_string
 2,36%  [kernel]             [k] __link_path_walk
 1,81%  [kernel]             [k] _atomic_dec_and_lock
 1,49%  [kernel]             [k] kmem_cache_free
 1,37%  [kernel]             [k] kmem_cache_alloc
 1,35%  [kernel]             [k] __audit_syscall_exit
 1,24%  [kernel]             [k] established_get_next
 1,23%  [kernel]             [k] acl_permission_check
 1,19%  [kernel]             [k] fget_light
 0,94%  [kernel]             [k] page_fault
 0,90%  [kernel]             [k] ub_file_charge
 0,84%  [kernel]             [k] clear_page_c_e
 0,76%  [kernel]             [k] find_get_page
 0,76%  [kernel]             [k] memset
 0,75%  [kernel]             [k] audit_syscall_entry
 0,70%  [kernel]             [k] find_busiest_group
 0,69%  [kernel]             [k] dput_nocache
 0,67%  [kernel]             [k] list_del
 0,62%  [kernel]             [k] in_group_p
 0,60%  [kernel]             [k] follow_managed
 0,59%  [kernel]             [k] schedule
 0,56%  [kernel]             [k] _cond_resched
 0,51%  [kernel]             [k] unmap_vmas
 0,50%  [kernel]             [k] copy_user_generic_string
 0,50%  [kernel]             [k] system_call
 0,49%  [kernel]             [k] system_call_after_swapgs
 0,48%  [kernel]             [k] radix_tree_lookup_slot
 0,48%  [kernel]             [k] _spin_lock_irqsave

 

В общем трафик стал летать, ненужные проходы по многотысячным таблицам фильтров канули в прошлое и точность шейпинга радует как никогда :)

 

Разве что с IPv6 пока оставили линейные правила, не особо ясно, как его разбивать хэшем да и влом, честно говоря, уже 2 недели имени шейпера - сколько можно! :) Кому нужно шейпер на хэшах для OpenVZ - прошу в личку, с радостью поделюсь.

Share this post


Link to post
Share on other sites

Всем привет! :)

 

Причесал код в более-менее приятный вид и выложил на GitHub, прошу: https://github.com/FastVPSEestiOu/openvz-network-shaper

 

Кто поможет дописать хэш-классификацию для IPv6 буду бесконечно благодарен :)

Share this post


Link to post
Share on other sites

Превышение суммы rate всех классов над скоростью корневого класса, иначе говоря, oversubscription -- это нормальная ситуация для провайдера,

Это недопустимо.

Сумма CEIL может быть более RATE родительского класса, а вот сумма RATE дочерних НЕ может быть более RATE родительского класса.

Share this post


Link to post
Share on other sites

Сумма CEIL может быть более RATE родительского класса, а вот сумма RATE дочерних НЕ может быть более RATE родительского класса.

Может быть. Причем - вполне. Скорость правда будет равна сумме всех рэйтов в худшем случае (а не рэйту родительского класса), но то такое.

Share this post


Link to post
Share on other sites

NiTr0

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

Maximum rate this class and all its children are guaranteed. Mandatory.

Из серии - "Можно ли есть мухоморы? - Можно, только отравитесь."

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