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

Шейпер на 2.6.38 и igb

[РЕШЕНО]

ответ в конце сообщения


 

Софтроутер, Fedora 14, 2.6.38.8-35, NIC Intel 82576, драйвер не ядерный igb

 

eth0 и eth1 tso off tx on sg on gro off lro off gso off

 

Драйвер загружается с параметрами

 

options igb IntMode=2,2 InterruptThrottleRate=3,3 RSS=2,2

 

sysctl.conf

 

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 0
net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.accept_source_route = 1
kernel.sysrq = 1
kernel.panic = 30
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
net.ipv4.neigh.default.gc_thresh3 = 4096
net.ipv4.neigh.default.gc_thresh2 = 2048
net.ipv4.neigh.default.gc_thresh1 = 1024
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 8388608 16777216
net.ipv4.tcp_wmem = 4096 4194394 16777216
net.core.wmem_default = 4194394
net.core.rmem_default = 8388608
net.core.netdev_max_backlog = 2000
net.ipv4.tcp_max_syn_backlog = 1024
net.core.somaxconn = 262144
net.ipv4.tcp_timestamps = 1
net.ipv4.tcp_no_metrics_save = 0
net.netfilter.nf_conntrack_tcp_timeout_established = 3600
net.netfilter.nf_conntrack_tcp_timeout_time_wait = 120
net.netfilter.nf_conntrack_tcp_timeout_fin_wait = 120
net.netfilter.nf_conntrack_generic_timeout = 300
net.netfilter.nf_conntrack_max = 824288
net.netfilter.nf_conntrack_udp_timeout = 30
net.netfilter.nf_conntrack_udp_timeout_stream = 180
net.nf_conntrack_max = 824288
net.ipv4.tcp_max_tw_buckets = 262144
vm.swappiness=5

 

eth0 поделен на eth0.10/100/552

eth1 поделен на eth1.87/217

 

По умолчанию бесклассовая дисциплина на физ.интерфейсах выглядит:

 

# tc qdisc show
qdisc mq 0: dev eth0 root
qdisc mq 0: dev eth1 root

 

С такой конфигурацией шейпера (вернее его "отсутствии") машина показывает хорошие результаты роутинга пакетов в районе 120kpps. Но стОит добавить хоть одину дисциплину очереди(любую) к VLAN-интерфейсу, допустим:

 

tc qdisc add dev eth0.10 root handle 1: htb

 

как сразу же число обрабатываемых пакетов снижается до уровня ~80-90kpps, абоненты начинают кричать, что всё тормозит. Появляются 1-2% потери по пингу. CPU utilization снижается вместе с pps, до уровня среднего при 80-90kpps.

 

При нагрузке - ДО 80kpps, аналогичного падения pps не замечено. То есть до 80kpps всё роутится+шейпится отлично, если выше - начинаются тормоза. Предпринимал попытки заменить очередь на физических интерфейсах c mq на pfifo (стандартная для большинства linux систем), но проблема остается абсолютно такой-же. Пробовал менять ядра на 2.6.30 и 2.6.35, там подобных проблем не наблюдается, но мне нужно 38-е ядро.

 

upd. на сервере используется NAT

 

updd. при присоединении к VLAN-интерфейсу любой дисциплины очереди (htb, pfifo, hfsc, tbf..) пакеты на данном интерфейсе начинают дико дропаться вне зависимости от конфигурации очереди

 

Ребят, помогите?


 

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

Опишу наглядно с примером в пределах одного интерфейса.

 

/sbin/tc qdisc del dev eth0.10 root
/sbin/tc qdisc add dev eth0.10 root handle 1: htb default 10
/sbin/tc class add dev eth0.10 parent 1: classid 1:1 htb rate 1000Mbit burst 1280k cburst 1280k
/sbin/tc class add dev eth0.10 parent 1:1 classid 1:10 htb rate 100Mbit ceil 1000Mbit burst 1280k cburst 1280k
/sbin/tc class add dev eth0.10 parent 1:1 classid 1:11 htb rate 1Mbit ceil 25Mbit burst 64k cburst 64k quantum 9000 #elcom 
/sbin/tc class add dev eth0.10 parent 1:1 classid 1:13 htb rate 100Kbit ceil 2Mbit burst 4k cburst 4k #privb10
/sbin/tc class add dev eth0.10 parent 1:1 classid 1:14 htb rate 100Kbit ceil 2Mbit burst 4k cburst 4k #privb
/sbin/tc class add dev eth0.10 parent 1:1 classid 1:15 htb rate 100Kbit ceil 2Mbit burst 4k cburst 4k #kspz

/sbin/tc qdisc add dev eth0.10 parent 1:10 handle 10: sfq perturb 10
/sbin/tc qdisc add dev eth0.10 parent 1:11 handle 11: sfq perturb 10
/sbin/tc qdisc add dev eth0.10 parent 1:13 handle 13: sfq perturb 10
/sbin/tc qdisc add dev eth0.10 parent 1:14 handle 14: sfq perturb 10
/sbin/tc qdisc add dev eth0.10 parent 1:15 handle 15: sfq perturb 10
#Создаем корневой фильтр
/sbin/tc filter add dev eth0.10 parent 1: protocol ip u32
#Создаем хеш таблицу для 10.230.109.0/24
/sbin/tc filter add dev eth0.10 parent 1:0 handle 63: protocol ip u32 divisor 256
#Добавляем правило в хеш таблицу, если ip dst входит в 10.230.109.0.24, то оправляем пакет в 63 хеш таблицу
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 800:: match ip dst 10.230.109.0/24 hashkey mask 0xff at 16 link 63:
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 63:61: match ip dst 10.230.109.97/32 flowid 1:13 #privb10
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 63:63: match ip dst 10.230.109.99/32 flowid 1:14 #privb
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 1 u32 ht 63:1b: match ip dst 10.230.109.27/32 flowid 1:15 #kspz
#если пакет из этой подсети не входит в указанную выше маску, отправляется в 10 класс
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 2 u32 ht 63:: match ip dst 10.230.109.0/24 flowid 1:10 #all
#ну и еще разные правила
#24.53.192.0/18
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 24.53.192.0/18 flowid 1:11
#86.34.96.0/19
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 86.34.96.0/19 flowid 1:11
#53.167.192.0/19
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 53.167.192.0/19 flowid 1:11
#159.236.192.0/18
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 159.236.192.0/18 flowid 1:11
#56.27.48.0/20
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 56.27.48.0/20 flowid 1:11
#78.28.192.0/19
/sbin/tc filter add dev eth0.10 parent 1:0 protocol ip prio 14 u32 match ip src 78.28.192.0/19 flowid 1:11

 

Так вот, в ранних ядрах 2.6.30 и 2.6.35 я мог опустить 10 подкласс с конечной дисциплиной этого класса и отправлять пакеты не прошедшие фильтры сразу в 1 класс.

В версиях 2.6.38 2.6.39, по какой-то причине пакеты отправленные в default 1 дропались с огромной скоростью.

 

Спасибо @nuclearcat, за подсказку.

Edited by 6yktonox

Share this post


Link to post
Share on other sites

Проверьте, куда направляются прерывания от очередей, и какие очереди задествованы.

 

cat /proc/cpuinfo

tc -s qdisc show dev ...

Share this post


Link to post
Share on other sites

# cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3
  0:        126          0          1          0   IO-APIC-edge      timer
  1:          0          2          0          0   IO-APIC-edge      i8042
  8:          0          0          0          0   IO-APIC-edge      rtc0
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          0          1          1          2   IO-APIC-edge      i8042
 14:     257171     246715     240383     233445   IO-APIC-edge      ata_piix
 15:         25         25         24         23   IO-APIC-edge      ata_piix
 16:         67         71         66         70   IO-APIC-fasteoi   uhci_hcd:usb2
 19:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 23:          0          0          1          1   IO-APIC-fasteoi   ehci_hcd:usb1
 66:          0          0          0          1   PCI-MSI-edge      eth0
 67:  919271050      28651      26148      26410   PCI-MSI-edge      eth0-TxRx-0
 68:      27895  929404291     517825      29225   PCI-MSI-edge      eth0-TxRx-1
 69:          0          1          0          0   PCI-MSI-edge      eth1
 70:     565595      32176  982915375      30595   PCI-MSI-edge      eth1-TxRx-0
 71:      29936      30076     542977  973183604   PCI-MSI-edge      eth1-TxRx-1
NMI:          0          0          0          0   Non-maskable interrupts
LOC:   82658677   82661592  106820224  106847889   Local timer interrupts
SPU:          0          0          0          0   Spurious interrupts
PMI:          0          0          0          0   Performance monitoring interrupts
IWI:          0          0          0          0   IRQ work interrupts
RES:      14649      19405      29739      25351   Rescheduling interrupts
CAL:     152174     118661      24550      22571   Function call interrupts
TLB:      10202       8371      34320      35276   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
MCE:          0          0          0          0   Machine check exceptions
MCP:        529        529        529        529   Machine check polls
ERR:          0
MIS:          0

 

# cat /proc/cpuinfo
processor       : 0/1/2/3
vendor_id       : GenuineIntel
cpu family      : 15
model           : 4
model name      : Intel(R) Xeon(TM) CPU 3.00GHz
stepping        : 3
cpu MHz         : 2992.803
cache size      : 2048 KB
physical id     : 0/3/0/3
siblings        : 2
core id         : 0
cpu cores       : 1
apicid          : 0/6/1/7
initial apicid  : 0/6/1/7
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 5
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss
ht tm pbe lm constant_tsc pebs bts pni dtes64 monitor ds_cpl cid cx16 xtpr
bogomips        : 5983.82
clflush size    : 64
cache_alignment : 128
address sizes   : 36 bits physical, 48 bits virtual

 

# tc -s qdisc
qdisc mq 0: dev eth0 root
Sent 257597591524 bytes 287932088 pkt (dropped 0, overlimits 0 requeues 232)
backlog 0b 0p requeues 232
qdisc mq 0: dev eth1 root
Sent 127122172198 bytes 263637164 pkt (dropped 0, overlimits 0 requeues 308)
backlog 0b 0p requeues 308

 

16 классов по умолчанию для eth0

# tc -s class show dev eth0
class mq :1 root
Sent 130730502047 bytes 146647806 pkt (dropped 0, overlimits 0 requeues 138)
backlog 0b 0p requeues 138
class mq :2 root
Sent 129697216820 bytes 144420824 pkt (dropped 0, overlimits 0 requeues 96)
в следующие классы :3,:4 и т.д. пакеты не попадают
т.е.
class mq :3 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0 
и т.д.

 

такая же картина с eth1

# tc -s class show dev eth1
class mq :1 root
Sent 67825856405 bytes 139419999 pkt (dropped 0, overlimits 0 requeues 168)
backlog 0b 0p requeues 168
class mq :2 root
Sent 63489604709 bytes 132177418 pkt (dropped 0, overlimits 0 requeues 145)
backlog 0b 0p requeues 145
class mq :3 root
Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
и т.д.

 

повторюсь.

Но стОит добавить хоть один корневой класс к VLAN-интерфейсу, допустим:

 

tc qdisc add dev eth0.10 root handle 1: htb

как сразу же число обрабатываемых пакетов снижается

Edited by 6yktonox

Share this post


Link to post
Share on other sites

Попробуйте убрать HTB, используйте HFSC.

Edited by Alex/AT

Share this post


Link to post
Share on other sites

updd. при присоединении к VLAN-интерфейсу любой дисциплины очереди (htb, pfifo, hfsc, tbf..) пакеты на данном интерфейсе начинают дико дропаться вне зависимости от конфигурации очереди

Share this post


Link to post
Share on other sites

а queue (qdisc) добавляете?

в том то и дело, при добавлении очереди

tc qdisc add dev eth0.10 root handle 1: htb

или

tc qdisc add dev eth0.10 root handle 1: pfifo

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

 

Напомню, по умолчанию у меня такие очереди для физ.интерфейсов

# tc qdisc show
qdisc mq 0: dev eth0 root
qdisc mq 0: dev eth1 root

 

Смена очереди на физ.интерфейсах, не дает результатов также.

 

UPD

 

Я понимаю, что проблема не наблюдается на 2.6.30 и 2.6.35, а это значит, что либо 38-е ядро кривое, либо в нем появились какие-то новые параметры, на которые я не обращаю внимания. Не припомните, что-то новое в 38-м появилось касательно шейпинга? Если совсем будет глухо, попробую перейти на 39-е

Edited by 6yktonox

Share this post


Link to post
Share on other sites

Достаточно много, там постоянно фиксы

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

Share this post


Link to post
Share on other sites

перешли на 2.6.39.3

картина следующая. пакеты дропаются с нереальной скоростью при добавлении любого qdisc

 

# tc qdisc add dev eth0.10 root handle 1: pfifo

через 10 секунд

# tc -s qdisc show dev eth0.10
qdisc pfifo 1: root refcnt 2 limit 1p
Sent 394574230 bytes 382266 pkt (dropped 966, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

имеем порядка 996 dropped из 382266 pkt

 

Меняю очередь на htb

# tc qdisc add dev eth0.10 root handle 1: htb

так-же снимаем данные через 10 секунд

# tc -s qdisc show dev eth0.10
qdisc htb 1: root refcnt 2 r2q 10 default 0 direct_packets_stat 384368
Sent 372025931 bytes 384368 pkt (dropped 3796, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

соответственно с htb, 3796 dropped из 384368 pkt

 

С hfsc

# tc qdisc add dev eth0.10 root handle 1: hfsc

аналогично, 10 секунд

# tc -s qdisc show dev eth0.10
qdisc hfsc 1: root refcnt 2
Sent 372734185 bytes 386391 pkt (dropped 14283, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

14283 dropped из 386391 pkt

 

Параметры очередей не указывал специально, что в принципе не важно, с ними ситуация не меняется.

На 2.6.30 и 2.6.35 такого количества dropped pkt не наблюдается (практически равно нулю).

 

Хочется все-таки докопаться до причины

Edited by 6yktonox

Share this post


Link to post
Share on other sites

tc qdisc add dev eth0.10 pfifo limit 10000

# tc qdisc add dev eth0.10 root pfifo limit 10000

# tc -s -d qdisc show dev eth0.10
qdisc pfifo 800a: root refcnt 2 limit 10000p
Sent 357587609 bytes 385271 pkt (dropped 0, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

 

# tc qdisc add dev eth0.10 root htb r2q 1500

# tc -s -d qdisc show dev eth0.10
qdisc htb 800e: root refcnt 2 r2q 1500 default 0 direct_packets_stat 381296 ver 3.17
Sent 317206549 bytes 381296 pkt (dropped 4958, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

 

Мне крайне необходим htb с его классами

Share this post


Link to post
Share on other sites

Тогда добавляйте сразу с классами

 

tc qdisc add dev eth0.10 root handle 1: htb default 1

tc class add dev eth0.10 classid 1:1 htb rate 1000Mbit ceil 1000Mbit

tc qdisc add dev eth0.10 parent 1:1 handle 10: pfifo limit 10000

Share this post


Link to post
Share on other sites

Просто если вы добавляете голый htb, у него нет "буфера" (qdisc), т.е. если пакет не передан сразу а должен быть сбуферизирован - оно его дропнет тут же

Share this post


Link to post
Share on other sites

Просто если вы добавляете голый htb, у него нет "буфера" (qdisc), т.е. если пакет не передан сразу а должен быть сбуферизирован - оно его дропнет тут же

 

А не подскажите как обстоят дела с буферизацией у qdisc который добавляет по умолчанию igb драйвер.

 

tc -s -d qdisc show dev eth0

qdisc mq 0: root

Sent 366910808207 bytes 638315270 pkt (dropped 0, overlimits 0 requeues 54620)

backlog 0b 0p requeues 54620

 

Нужно ли на вланы этого интерфейса делать tc qdisc add dev eth0.10 root pfifo limit 1000?

Заранее спасибо за ответ.

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