[libbkmz]

Доброго времени суток всем. Наконецто нашел место, где могу поделится проблемой. Имеется сервер

Dell PowerEdge C5220.

Intel® Xeon® CPU E3-1240 V2 @ 3.40GHz.

32Gb RAM.

02:00.0 Ethernet controller: Intel Corporation 82580 Gigabit Network Connection (rev 01)

 

Есть 1 канал в интернет гигабитный. Уже неделю ддосят SYN флудом на 80ый порт.

 

   10 root      20   0     0    0    0 R  55.6  0.0   6:02.59 [ksoftirqd/1]                                                                            
  55 root      20   0     0    0    0 R  43.6  0.0   1:40.41 [kworker/1:1] 

 

iptables-save:

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [152880217:6729982268]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -m limit --limit 1/sec -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -m tcp --dport 80 --tcp-flags FIN,SYN,RST,ACK SYN -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-unreachable
COMMIT
# Completed on Fri Oct 11 21:15:16 2013

 

42:          2          0          0          0          1          0          0          0   PCI-MSI-edge      eth0
43:     601076     218288      64258      24948    1564132    1175414     403022      37295   PCI-MSI-edge      eth0-TxRx-0
44:     599887     218392      63762      24252    1566807    1168281     402363      36032   PCI-MSI-edge      eth0-TxRx-1
45:     599751     217962      63890      25199    1564680    1177650     401688      37529   PCI-MSI-edge      eth0-TxRx-2
46:     600021     217294      64930      24392    1564343    1175429     400466      37122   PCI-MSI-edge      eth0-TxRx-3
47:     599981     218459      63912      24411    1563261    1174937     402381      36073   PCI-MSI-edge      eth0-TxRx-4
48:     601200     217621      64201      25264    1568327    1172853     403133      38079   PCI-MSI-edge      eth0-TxRx-5
49:     619500     228748      68688      26215    1505128    1251548     423854      42516   PCI-MSI-edge      eth0-TxRx-6
50:     598713     218411      64000      25328    1561667    1179157     403728      37784   PCI-MSI-edge      eth0-TxRx-7

 

net.ipv4.icmp_echo_ignore_all = 1

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv4.conf.all.send_redirects = 0

net.ipv4.tcp_max_orphans = 65536

net.ipv4.tcp_abort_on_overflow = 0

#try to increase
net.ipv4.tcp_max_syn_backlog = 128000
net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_congestion_control = htcp
net.ipv4.tcp_no_metrics_save = 1

net.ipv4.ip_local_port_range = 20000 65535

net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_rfc1337 = 1

net.core.netdev_max_backlog = 65535


net.netfilter.nf_conntrack_tcp_timeout_syn_sent = 5
net.netfilter.nf_conntrack_max=1048576

net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_syncookies = 1
net.core.somaxconn = 262144

net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_max_syn_backlog = 65536
net.core.wmem_max = 8388608
net.core.rmem_max = 8388608

net.core.optmem_max = 35500

 

ethtool -G eth0 rx 4096 tx 4096

 

Это текущее состояние, при котором на 80йы порт легитимные запросы получают ответы в течении пары секунд. Но иногда атака усиливается и этого не спасает. Как только убираю --dport 80 -j ACCEPT сразу в топе становится пусто. Или делаю -P INPUT DROP и потом -F INPUT получаю пустой top.

 

netstat -tuna | grep SYN | wc -l
14637

Средний kpps за минуту 250.

 

Если очистить iptables и сделать -P INPUT ACCEPT получаю туже самую картину с ksoftirqd. Вопрос в том, как правильно разрулить ситуацию с кучей SYN пакетов?

Изменено 11 октября, 2013 пользователем libbkmz

[vitalyb]

libbkmz

Прерывания очередей надо прибивать к реальным ядрам цпу через smp affinity.

 

SYN cookies пробовали?

[libbkmz]

SYN cookies пробовали?

 

Оно не включается. Когда синфлуд был на другой порт. Включение кук вешало сервак намертво. Сейчас что с ними что без них - одинаково. в dmesg нету никакой информации про включение их.

 

Прерывания очередей надо прибивать к реальным ядрам цпу через smp affinity.

 

Сейчас выключил HT.

42:          1          0          0          0   PCI-MSI-edge      eth0
43:     528955      24465      47342      29926   PCI-MSI-edge      eth0-rx-0
44:     529714      24027      47614      29856   PCI-MSI-edge      eth0-rx-1
45:     530784      23869      47813      29782   PCI-MSI-edge      eth0-rx-2
46:     530765      23960      48059      30176   PCI-MSI-edge      eth0-rx-3
47:         65          0          3          4   PCI-MSI-edge      eth0-tx-0
48:         97          3          1          1   PCI-MSI-edge      eth0-tx-1
49:     112094      32852       8064       2664   PCI-MSI-edge      eth0-tx-2
50:        115          3          0          1   PCI-MSI-edge      eth0-tx-3

 

Вот выдача perf top:

 

 

Изменено 11 октября, 2013 пользователем libbkmz

[vitalyb]

libbkmz

eth0-rx-0 и eth0-tx-0 должны быть назначены на CPU0, 1 - на 1 и т.д., см. /proc/irq/42/smp_affinity

 

conntrack, наверно, лучше выключить - см. iptables -t raw

[morfair]

Слышал, что для роутинга (сервера доступа) в BIOS'е поддержку виртуализации лучше выключить. Правда, что это как то влияет ан производительность?

[Ilya Evseev]

Слышал, что для роутинга (сервера доступа) в BIOS'е поддержку виртуализации лучше выключить. Правда, что это как то влияет ан производительность?

Да. OOB и прочее.

 

http://forum.nag.ru/forum/index.php?showtopic=86243&view=findpost&p=854847

[morfair]

Слышал, что для роутинга (сервера доступа) в BIOS'е поддержку виртуализации лучше выключить. Правда, что это как то влияет ан производительность?

Да. OOB и прочее.

 

http://forum.nag.ru/forum/index.php?showtopic=86243&view=findpost&p=854847

А OOB что такое?) Можно какое-то предписание получить, списочек небольшой)

[Ilya Evseev]

А OOB что такое?)

http://en.wikipedia.org/wiki/Out-of-band_management

[kayot]

http://en.wikipedia.org/wiki/Out-of-band_management

А зачем его выкашивать то? У меня когда-то чудеса давал IPMI-драйвер на старом супермикровском сервере(под 775ый сокет), обеспечивая 100% загрузку 1 ядра при любом трафике. И это при том, что физически IPMI-платы в сервере не было :)

Но это явно баг древнего федоровского дистрибутива, больше подобного свинства не встречал.

[Painter]

Linux 3.10.12, SMP, x86_64

CONFIG_HZ: 1000

Xeon E31220 4x3.10GHz

2xIntel 82599EB 10-Gigabit + гигабитные SFP

Через этот сервер проходит дамп реального трафика юр. лиц, снятый на другом сервере, В один интерфейс входит, из другого выходит.

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

Шейпер на хешах+HTB.

"tc filter ls dev eth0 | grep filter | wc -l" - 8141

Clocksource: TSC

Suricata (но она дает практически незаметную нагрузку, там проверяется только http host для трафика на заблокированные IP из реестра)

Блокировование абонентов и отправка трафика в сурикату с помощью ipset.

Трафик - 945/325 Мбит/с

240K - PPS (in+out на одном интерфейсе)

 

dstat --time --all --top-cpu
----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- -most-expensive-
    time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw |  cpu process   
04-10 11:12:30|  0   0  68   0   0  33|   0     0 | 156M  140M|   0     0 | 239k 7590 |ksoftirqd/3  0.2
04-10 11:12:31|  0   0  70   0   0  30|   0     0 | 156M  141M|   0     0 | 241k 7941 |suricata     0.5
04-10 11:12:32|  0   0  68   0   0  31|   0     0 | 158M  138M|   0     0 | 244k 7908 |ksoftirqd/1  0.2
04-10 11:12:33|  0   0  68   0   0  32|   0     0 | 154M  142M|   0     0 | 238k 7801 |suricata     0.2
04-10 11:12:34|  0   0  69   0   0  30|   0     0 | 151M  139M|   0     0 | 235k 7688 |suricata     0.2

 

Включаем в ядре CONFIG_NO_HZ=y

dstat --time --all --top-cpu
----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- -most-expensive-
    time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw |  cpu process   
04-10 16:36:10|  1   0  99   0   0   1|   0     0 | 157M  141M|   0     0 | 254k 6683 |suricata     0.2
04-10 16:36:11|  0   0  99   0   0   1|   0     0 | 158M  139M|   0     0 | 258k 7054 |suricata     0.2
04-10 16:36:12|  0   0  99   0   0   0|   0    12k| 152M  141M|   0     0 | 248k 6403 |ksoftirqd/3  0.2
04-10 16:36:13|  0   0  99   0   0   0|   0     0 | 153M  140M|   0     0 | 248k 6472 |suricata     0.2
04-10 16:36:14|  0   0  99   0   0   0|   0     0 | 155M  140M|   0     0 | 252k 6722 |suricata     0.2

 

Нагрузка от softirq упала в 30 раз. Как так?

На графиках загруки CPU в Munin видно, что перестает обновляться idle счетчик для процессоров.

 

Включаем ядре CONFIG_IRQ_TIME_ACCOUNTING вместо CONFIG_TICK_CPU_ACCOUNTING (включен по-умолчанию)

dstat --time --all --top-cpu
----system---- ----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system-- -most-expensive-
    time     |usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw |  cpu process   
08-10 11:01:09|  0   0  78   0   2  20|   0    20k| 151M  139M|   0     0 | 225k 6379 |suricata     0.2
08-10 11:01:10|  0   0  77   0   2  21|   0     0 | 155M  140M|   0     0 | 228k 6286 |ksoftirqd/0  0.2
08-10 11:01:11|  0   0  77   0   2  22|   0     0 | 157M  142M|   0     0 | 230k 6519 |suricata     0.2
08-10 11:01:12|  0   0  76   0   2  22|   0    24k| 158M  139M|   0     0 | 235k 6537 |suricata     0.2
08-10 11:01:13|  0   0  78   0   2  20|   0     0 | 150M  140M|   0     0 | 224k 6242 |snmpd        0.2

 

cat /proc/interrupts | grep -E "(eth0|eth1)"
55:   27938908          0          0          0   PCI-MSI-edge      eth1-TxRx-0
56:         37   26069987          0          0   PCI-MSI-edge      eth1-TxRx-1
57:         33          0   22079340          0   PCI-MSI-edge      eth1-TxRx-2
58:         33          0          0   27743055   PCI-MSI-edge      eth1-TxRx-3
59:       1138          0          0          0   PCI-MSI-edge      eth1
66:   27448673          0          0          0   PCI-MSI-edge      eth0-TxRx-0
67:         34   24922850          0          0   PCI-MSI-edge      eth0-TxRx-1
68:         31          0   21369116          0   PCI-MSI-edge      eth0-TxRx-2
69:         31          0          0   27589854   PCI-MSI-edge      eth0-TxRx-3
70:       1065          0          0          0   PCI-MSI-edge      eth0

 

  PerfTop:     894 irqs/sec  kernel:99.8%  exact:  0.0% [4000Hz cycles],  (all, 4 CPUs)
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------                                                               

    8.15%  [kernel]            [k] ipt_do_table                  
    5.47%  [ixgbe]             [k] ixgbe_poll                    
    5.23%  [sch_htb]           [k] htb_dequeue                   
    4.41%  [kernel]            [k] _raw_spin_lock                
    3.78%  [kernel]            [k] lapic_next_deadline           
    3.77%  [ip_set_hash_net]   [k] hash_net4_test                
    2.86%  [cls_u32]           [k] u32_classify                  
    2.29%  [kernel]            [k] _raw_read_lock_bh             
    2.04%  [ixgbe]             [k] ixgbe_xmit_frame_ring         
    1.96%  [kernel]            [k] menu_select                   
    1.76%  [ip_set]            [k] ip_set_test                   
    1.70%  [kernel]            [k] apic_timer_interrupt          
    1.66%  [kernel]            [k] irq_entries_start             
    1.43%  [kernel]            [k] ip_route_input_noref          
    1.37%  [kernel]            [k] rb_erase                      
    1.30%  [kernel]            [k] nf_iterate                    
    1.24%  [kernel]            [k] _raw_spin_lock_irqsave        
    1.23%  [kernel]            [k] irqtime_account_irq           
    1.18%  [kernel]            [k] fib_table_lookup              
    1.16%  [sch_htb]           [k] htb_add_to_wait_tree          
    1.15%  [kernel]            [k] cpuidle_enter_state           
    1.12%  [kernel]            [k] native_sched_clock            
    1.11%  [kernel]            [k] local_bh_enable_ip            
    1.08%  [kernel]            [k] int_sqrt                      
    0.97%  [kernel]            [k] _raw_read_unlock_bh           
    0.96%  [kernel]            [k] check_leaf.isra.9             
    0.92%  [sch_htb]           [k] htb_enqueue                   
    0.92%  [kernel]            [k] timerqueue_add                
    0.91%  [kernel]            [k] dev_queue_xmit                
    0.87%  [kernel]            [k] ktime_get                     
    0.85%  [kernel]            [k] build_skb                     
    0.84%  [kernel]            [k] qdisc_dequeue_head            
    0.83%  [kernel]            [k] read_tsc                      
    0.78%  [kernel]            [k] __netif_receive_skb_core      
    0.74%  [kernel]            [k] add_interrupt_randomness      
    0.73%  [kernel]            [k] __qdisc_run                   
    0.68%  [kernel]            [k] ip_rcv                        
    0.67%  [kernel]            [k] __netdev_alloc_frag           
    0.67%  [kernel]            [k] ip_finish_output              
    0.65%  [kernel]            [k] kmem_cache_alloc              
    0.65%  [sch_htb]           [k] htb_lookup_leaf               
    0.62%  [kernel]            [k] local_bh_enable               
    0.60%  [kernel]            [k] sched_clock_cpu               
    0.59%  [kernel]            [k] get_nohz_timer_target         
    0.59%  [kernel]            [k] find_next_bit                 
    0.57%  [kernel]            [k] __hrtimer_start_range_ns      
    0.55%  [kernel]            [k] rb_first                      
    0.54%  [kernel]            [k] common_interrupt              
    0.53%  [kernel]            [k] rcu_eqs_enter_common.isra.51  
    0.53%  [kernel]            [k] rcu_eqs_exit_common.isra.49   
    0.50%  [kernel]            [k] clockevents_program_event     
    0.49%  [kernel]            [k] __tick_nohz_idle_enter        
    0.46%  [kernel]            [k] get_next_timer_interrupt      
    0.46%  [kernel]            [k] cpu_startup_entry             
    0.44%  [kernel]            [k] net_tx_action                 
    0.41%  [xt_set]            [k] set_match_v1                  
    0.40%  libpthread-2.13.so  [.] __pthread_mutex_unlock_usercnt
    0.40%  [kernel]            [k] _raw_spin_unlock_irqrestore   
    0.40%  [ip_set_hash_net]   [k] hash_net4_kadt                
    0.39%  [kernel]            [k] memcpy                        
    0.39%  [kernel]            [k] irq_exit

 

ethtool -i eth0
driver: ixgbe
version: 3.17.3
firmware-version: 0x61c10001

 

ethtool --show-offload eth0
Features for eth0:
rx-checksumming: on
tx-checksumming: on
       tx-checksum-ipv4: on
       tx-checksum-ip-generic: off [fixed]
       tx-checksum-ipv6: on
       tx-checksum-fcoe-crc: off [fixed]
       tx-checksum-sctp: on
scatter-gather: on
       tx-scatter-gather: on
       tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: off
       tx-tcp-segmentation: off
       tx-tcp-ecn-segmentation: off [fixed]
       tx-tcp6-segmentation: off
udp-fragmentation-offload: off [fixed]
generic-segmentation-offload: off
generic-receive-offload: off
large-receive-offload: off
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: on [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: on
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off [fixed]
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]

 

ethtool --show-coalesce eth0
Coalesce parameters for eth0:
Adaptive RX: off  TX: off
stats-block-usecs: 0
sample-interval: 0
pkt-rate-low: 0
pkt-rate-high: 0

rx-usecs: 1
rx-frames: 0
rx-usecs-irq: 0
rx-frames-irq: 0

tx-usecs: 0
tx-frames: 0
tx-usecs-irq: 0
tx-frames-irq: 256

rx-usecs-low: 0
rx-frame-low: 0
tx-usecs-low: 0
tx-frame-low: 0

rx-usecs-high: 0
rx-frame-high: 0
tx-usecs-high: 0
tx-frame-high: 0

 

modprobe ixgbe allow_unsupported_sfp=1,1 LRO=0

 

Распределение пакетов по очередям:

tx_queue_0_packets: 24.98kpps
tx_queue_1_packets: 25.84kpps
tx_queue_2_packets: 31.90kpps
tx_queue_3_packets: 23.53kpps

rx_queue_0_packets: 29.71kpps
rx_queue_1_packets: 26.14kpps
rx_queue_2_packets: 31.48kpps
rx_queue_3_packets: 40.72kpps

 

Распределение прерываний по очередям

Eth0-TxRx-0: 13.37k
Eth0-TxRx-1: 12.12k
Eth0-TxRx-2: 10.37k
Eth0-TxRx-3: 12.37k

Eth1-TxRx-0: 13.68k
Eth1-TxRx-1: 12.84k
Eth1-TxRx-2: 10.84k
Eth1-TxRx-3: 13.71k

 

SoftInterrupts:

NET_TX: 120к
NET_RX: 100к
HR_TIMER: 5.45к  

 

По моим тестам tickless ядро дает меньшую нагрузку на процессор (на 10%, еще -2% CPU_HOTPLUG=n).

Отключение iptables: 7%

Замена tsc на hpet или acpi_pm сказывается крайне негативно на загрузке CPU.

Сейчас используется CONFIG_NOHZ+CONFIG_IRQ_TIME_ACCOUNTING, Softirq: 20-22%

 

Собственно вопросы:

1. 1-3% нагрузки на CPU с CONFIG_NOHZ+CONFIG_TICK_CPU_ACCOUNTING - она на самом деле такая низкая или просто не учитывается? Похоже на подставу :) сейчас я по-крайней мере вижу зависимость нагрузки от трафика.

2. Для этого сервера это нормальная нагрузка (20-22% Softirq)? и можно ли ее еще уменьшить? (кроме варианта отключения iptables, шейпера, сурикаты)?

3. Почему включение оффлоадингов уменьшает нагрузку на процессор на 2%? (context switches уменьшаются на 1к - и на 10к прерывания). Но я в этой теме читал, что это плохо влияет на шейпер, поэтому оффлоадинги отключены).

4. 120к прерываний Local Timer Interrupts - Это нормально? (их можно сделать меньше, если раскидать прерывания от сетевушек на 2 процессора или все на один. Тогда снижается до 70к).

Изменено 15 октября, 2013 пользователем Painter

[Painter]

Сервер из предыдущего сообщения...

 

Переделал шейпер c HTB+pfifo на HFSC+sfq, нагрузка возросла на 6%, а не снизилась в 2-3 как тут писали выше. Так же увеличилось количество переключений контекста с 5,5к до 11к (в 2 раза)

 

Шейпер генерируется примерно так:

# HTB+PFIFO
#qdisc add dev eth0 root handle 10: htb
#class replace dev eth0 parent 10: classid 10:0 htb rate 10000Mbit
#qdisc add dev eth1 root handle 10: htb
#class replace dev eth1 parent 10: classid 10:0 htb rate 10000Mbit
#
#class replace dev eth0 parent 10:1 classid 10:1237 htb rate 512kbit
#qdisc replace dev eth0 parent 10:1237 handle 1237 pfifo limit 50
#class replace dev eth1 parent 10:1 classid 10:1237 htb rate 512kbit
#qdisc replace dev eth1 parent 10:1237 handle 1237 pfifo limit 50
#...

# HFSC+SFQ
# Корневой класс для клиентов 
qdisc add dev eth0 root handle 10: est 1s 10s hfsc default 2
class replace dev eth0 parent 10: classid 10:1 hfsc sc rate 10gbit ul rate 10gbit
qdisc add dev eth1 root handle 10: est 1s 10s hfsc default 2
class replace dev eth1 parent 10: classid 10:1 hfsc sc rate 10gbit ul rate 10gbit

# Дефолтный класс для всего неклассифицируемого трафика
class replace dev eth0 parent 10: classid 10:2 hfsc sc rate 10gbit ul rate 10gbit
qdisc replace dev eth0 parent 10:2 handle 2 sfq
class replace dev eth1 parent 10: classid 10:2 hfsc sc rate 10gbit ul rate 10gbit
qdisc replace dev eth1 parent 10:2 handle 2 sfq

# Классы клиентов
class replace dev eth0 parent 10:1 classid 10:1237 hfsc sc rate 512kbit ul rate 512kbit
qdisc replace dev eth0 parent 10:1237 handle 1237 sfq
class replace dev eth1 parent 10:1 classid 10:1237 hfsc sc rate 512kbit ul rate 512kbit
qdisc replace dev eth1 parent 10:1237 handle 1237 sfq
... еще 3500 классов и дисциплин

# Фильтры на хешах
filter add dev eth0 protocol ip prio 5 parent 10:0 handle 200: u32 divisor 256
filter add dev eth1 protocol ip prio 5 parent 10:0 handle 200: u32 divisor 256
filter add dev eth0 protocol ip prio 5 parent 10:0 u32 ht 800:: match ip dst 10.245.0.0/22 hashkey mask 0x0000ff00 at 16 link 200:
filter add dev eth0 protocol ip prio 5 parent 10:0 u32 ht 800:: match ip src 10.245.0.0/22 hashkey mask 0x0000ff00 at 12 link 200:

# Много фильтров отправляющих трафик для каждого ip в свой класс...
filter add dev eth0 protocol ip prio 5 parent 10:0 handle 82: u32 divisor 256
filter add dev eth1 protocol ip prio 5 parent 10:0 handle 82: u32 divisor 256
filter add dev eth0 protocol ip prio 5 parent 10:0 u32 ht 200:1: match ip dst 10.245.1.0/24 hashkey mask 0x000000ff at 16 link 82:
filter add dev eth1 protocol ip prio 5 parent 10:0 u32 ht 200:1: match ip src 10.245.1.0/24 hashkey mask 0x000000ff at 12 link 82:
filter replace dev eth0 protocol ip prio 5 parent 10:0 u32 ht 82:7: match ip dst 10.245.1.7 classid 10:1192
filter replace dev eth1 protocol ip prio 5 parent 10:0 u32 ht 82:7: match ip src 10.245.1.7 classid 10:1192
filter replace dev eth0 protocol ip prio 5 parent 10:0 u32 ht 82:8: match ip dst 10.245.1.8 classid 10:1228
filter replace dev eth1 protocol ip prio 5 parent 10:0 u32 ht 82:8: match ip src 10.245.1.8 classid 10:1228

 

Скорости от 256 кбит до 100 мбит.

 

# HFSC+SFQ
  PerfTop:    2738 irqs/sec  kernel:99.3%  exact:  0.0% [4000Hz cycles],  (all, 4 CPUs)
----------------------------------------------------------------------------------------
    7.67%  [kernel]            [k] ipt_do_table                  
    6.97%  [kernel]            [k] _raw_spin_lock                
    4.48%  [ixgbe]             [k] ixgbe_poll                    
    3.62%  [ip_set_hash_net]   [k] hash_net4_test                
    2.50%  [cls_u32]           [k] u32_classify                  
    2.40%  [kernel]            [k] lapic_next_deadline           
    2.34%  [kernel]            [k] rb_first                      
    2.27%  [sch_hfsc]          [k] hfsc_dequeue                  
    2.14%  [sch_hfsc]          [k] cftree_insert                 
    2.00%  [ixgbe]             [k] ixgbe_xmit_frame_ring         
    1.96%  [sch_hfsc]          [k] eltree_insert                 
    1.94%  [sch_sfq]           [k] sfq_dequeue                   
    1.83%  [ip_set]            [k] ip_set_test                   
    1.44%  [kernel]            [k] rb_erase                      
    1.43%  [kernel]            [k] _raw_read_lock_bh             
    1.40%  [kernel]            [k] apic_timer_interrupt          
    1.35%  [sch_sfq]           [k] sfq_enqueue                   
    1.28%  [sch_hfsc]          [k] vttree_insert                 
    1.25%  [kernel]            [k] rb_insert_color               
    1.20%  [kernel]            [k] fib_table_lookup              
    1.17%  [kernel]            [k] menu_select                   
    1.12%  [sch_hfsc]          [k] hfsc_enqueue                  
    1.11%  [kernel]            [k] ktime_get                     
    1.07%  [kernel]            [k] cpuidle_enter_state           
    1.04%  [kernel]            [k] irq_entries_start             
    1.02%  [kernel]            [k] read_tsc

# HTB+PFIFO
  PerfTop:    1893 irqs/sec  kernel:98.9%  exact:  0.0% [4000Hz cycles],  (all, 4 CPUs)
----------------------------------------------------------------------------------------
    8.03%  [kernel]            [k] ipt_do_table                  
    4.99%  [ixgbe]             [k] ixgbe_poll                    
    4.37%  [sch_htb]           [k] htb_dequeue                   
    4.09%  [ip_set_hash_net]   [k] hash_net4_test                
    3.93%  [kernel]            [k] _raw_spin_lock                
    3.65%  [cls_u32]           [k] u32_classify                  
    2.97%  [kernel]            [k] lapic_next_deadline           
    2.18%  [ip_set]            [k] ip_set_test                   
    2.07%  [kernel]            [k] apic_timer_interrupt          
    2.03%  [ixgbe]             [k] ixgbe_xmit_frame_ring         
    1.89%  [kernel]            [k] _raw_read_lock_bh             
    1.65%  [kernel]            [k] fib_table_lookup              
    1.42%  [kernel]            [k] cpuidle_enter_state           
    1.42%  [sch_htb]           [k] htb_enqueue                   
    1.38%  [kernel]            [k] menu_select                   
    1.28%  [kernel]            [k] irq_entries_start             
    1.18%  [kernel]            [k] nf_iterate                    
    1.18%  [kernel]            [k] local_bh_enable_ip            
    1.14%  [kernel]            [k] dev_queue_xmit                
    1.12%  [kernel]            [k] read_tsc

 

_raw_spin_lock стало больше

Изменено 22 октября, 2013 пользователем Painter

[NiTr0]

iptables у вас основную нагрузку создает, поиск по таблицам.

[Painter]

Про iptables все понятно, туда еще не добрался для оптимизаций. Я ожидал, что после замены HTB на HFSC нагрузка станет меньше, но этого не произошло. Даже если сделать HFSC+pfifo нагрузка возрастает. Надо еще тестировать этот шейпер, посмотрю как он ограничивает скорость.

 

В целом считаю чтение этой темы очень полезным. Мне удалось снизить нагрузку на процессор на 10% не оптимизируя iptables и не меняя параметров NAPI (сейчас стоит rx-usecs=1, это "low latency" режим для ixgbe).

[Tamahome]

У меня когда-то чудеса давал IPMI-драйвер на старом супермикровском сервере

У меня в gentoo такое тоже было, вылечилось выбрасыванием ненужного модуля.

[Tamahome]

Вот с нагрузкой на 3.10.x у меня тоже странности, но откатился из-за зависаний на ровном месте, и "INFO: rcu_sched detected stalls on CPUs/tasks..." никак не связанных с нагрузкой

01:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
01:00.1 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)
05:00.0 Ethernet controller: Intel Corporation 82574L Gigabit Network Connection
00:19.0 Ethernet controller: Intel Corporation 82578DM Gigabit Network Connection (rev 05)

Проще говоря, 2 сетевухи "стрёмные", 1-2х портовая igb

Всё это добро собрано по 2 в bonding.

 

Роутер,шэйпер,ipset(вкл-выкл абонентов), нагрузка 1.4G/190Кpps

 

 

На 3.4.66 особо выделяются

[k] hpet_msi_next_event

[k] irq_entries_start

 

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

3.10 по крупнее:

Слева gentoo-3.10.x (от 3.10.7-r1 до 3.10.16 изменений не змечено/ с ~7.30 до ~15.00 это прерывания не раскиданы были.). Справа 3.4.66.

Изменено 29 октября, 2013 пользователем Tamahome

[tawer]

господа, присоветуйте:

есть машинка, далеко не топ, но стоит в продакшене на достаточно ответственном участке

конфиг: i7-2600K 3.40GHz,

ядро 2.6.27.62 (ванильное, насколько я помню)

Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01)

driver: ixgbe

version: 3.8.21-NAPI

HT включен в данный момент

драйвер грузится с параметрами /sbin/modprobe ixgbe IntMode=2 FdirMode=0 (соответственно, порождается 8 RxTx очередей), очереди прибиты последовательно к 4-7 ядрам).

с недавнего времени начал прирастать счетчик dropped на интерфейсе, ну и синхронно ему rx_missed_errors из ethtool -S, соответственно, появился некоторый процент потерь пакетов через данный роутер.

сделал /sbin/ethtool -A eth2 autoneg off tx off rx off, счетчики прирастать перестали, однако потери имеют место быть по прежнему, только теперь непонятно, где их отследить.. (интересно, кстати. может кто подскажет куда посмотреть?)

 

по факту существенно машинка не нагружена, idle редко опускается ниже 80%, загрузка ядер в отдельности не вылазит за 40-50%.

 

ну и для инфы:

ethtool -k eth2

Offload parameters for eth2:

Cannot get device GRO settings: Operation not supported

rx-checksumming: off

tx-checksumming: off

scatter-gather: off

tcp-segmentation-offload: off

udp-fragmentation-offload: off

generic-segmentation-offload: on

generic-receive-offload: off

large-receive-offload: off

ntuple-filters: off

receive-hashing: off

 

ethtool -g eth2

Ring parameters for eth2:

Pre-set maximums:

RX: 4096

RX Mini: 0

RX Jumbo: 0

TX: 4096

Current hardware settings:

RX: 2048

RX Mini: 0

RX Jumbo: 0

TX: 2048

 

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

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

 

так же прошу прощения за сумбурное оформление поста, писал с коленки... ;)

Изменено 29 октября, 2013 пользователем tawer

[srg555]

если у вас rx missed errors, то есть смысл rx буфер увеличить до максимума

[kayot]

IMHO все зло во включенном HT, прерывания прибиты не к физическим ядрам. Потому и загрузка не растет выше 50%, и потери начинаются.

[tawer]

если у вас rx missed errors, то есть смысл rx буфер увеличить до максимума

имеете ввиду Ring?

 

IMHO все зло во включенном HT, прерывания прибиты не к физическим ядрам. Потому и загрузка не растет выше 50%, и потери начинаются.

сам этим фактом не доволен, но, исторически сложилось так, а лишний раз перезагружать рутер для отключения фичи не получится.. (в смысле производить придется разом комплекс мероприятий при минимальном даунтайме, вот решил посоветоваться..)

Изменено 29 октября, 2013 пользователем tawer

[NiTr0]

Тогда хотя бы посмотрите, какие ядра физические, и прибейте к ним прерывания...

И да, ядро какбы того... обновить что ли. В свежих как минимум BKL выпилили. Да и выпиливание route cache, поговаривают, шибко прирост производительности дало...

[vitalyb]

выпиливание route cache, поговаривают, шибко прирост производительности дало...

Тут сильно зависит. Я "чуда" не заметил вообще, в частности по 2 причинам - route cache hash table был увеличен по сравнению с дефолтом, трафик был достаточно "хороший" для кеширования. Например на NAT с лимитом в 1М трансляций кешировать больше 2М маршрутов явно не надо. А вот прямая зависимость производительности от размера таблицы маршрутизации ощущается очень хорошо.

 

Жалобы на route cache в lkml попадались только, если склероз не изменяет, в плане "web сервер под ддосом" и что производительность кеша зависит от внешних факторов (непредсказуема в общем случае и подвержена dos), в отличии от, собтвенно, таблицы маршрутизации.

 

В процессе выпиливания были даже ядра, которые сами выключали кеш если, по их мнению, трафик шел "плохой". Было очень весело поймать эту фичу на роутере, когда он перешел в "предсказуемый режим черепахи" и просто помер под нагрузкой.

[s.lobanov]

kayot (Вчера, 23:34) писал:

IMHO все зло во включенном HT, прерывания прибиты не к физическим ядрам. Потому и загрузка не растет выше 50%, и потери начинаются.

 

сам этим фактом не доволен, но, исторически сложилось так, а лишний раз перезагружать рутер для отключения фичи не получится

 

ht можно софтового выключать:

# cat /opt/ht/noht.sh 
#!/bin/bash

cat /sys/devices/system/cpu/cpu*/topology/thread_siblings_list |
sort -u |
while read sibs
do
   case "$sibs" in
           *,*)
                   oldIFS="$IFS"
                   IFS=",$IFS"
                   set $sibs
                   IFS="$oldIFS"

                   shift
                   while [ "$1" ]
                   do
                           echo Disabling CPU $1 ..
                           echo 0 > /sys/devices/system/cpu/cpu$1/online
                           shift
                   done
                   ;;
           *)
                   ;;
   esac
done

 

Можно ли это сделать на вашем древнем ядре не знаю, скорее всего можно, если существуют /sys/devices/system/cpu/cpuX/online

[Tamahome]

Кто подскажет, куда копать для оптимизации?

8.61% [kernel] [k] fib_table_lookup

[morfair]

Интересует вопрос. При выборе процессора на форвардинг (плюс терминация VPN) стоит ли учитывать модель процессора (Intel Core 2 Quad, i5, i7, Xeon и т.д.) или в первую очередь нужно ориентироваться на количество ядер и тактовую частоту для обработки прерываний? Если да, то из каких соображений.

[NiTr0]

При выборе процессора на форвардинг (плюс терминация VPN) стоит ли учитывать модель процессора (Intel Core 2 Quad, i5, i7, Xeon и т.д.) или в первую очередь нужно ориентироваться на количество ядер и тактовую частоту для обработки прерываний?

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