libbkmz Опубликовано 11 октября, 2013 (изменено) · Жалоба Доброго времени суток всем. Наконецто нашел место, где могу поделится проблемой. Имеется сервер 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 11 октября, 2013 · Жалоба libbkmz Прерывания очередей надо прибивать к реальным ядрам цпу через smp affinity. SYN cookies пробовали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
libbkmz Опубликовано 11 октября, 2013 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 11 октября, 2013 · Жалоба libbkmz eth0-rx-0 и eth0-tx-0 должны быть назначены на CPU0, 1 - на 1 и т.д., см. /proc/irq/42/smp_affinity conntrack, наверно, лучше выключить - см. iptables -t raw Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 13 октября, 2013 · Жалоба Слышал, что для роутинга (сервера доступа) в BIOS'е поддержку виртуализации лучше выключить. Правда, что это как то влияет ан производительность? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 14 октября, 2013 · Жалоба Слышал, что для роутинга (сервера доступа) в BIOS'е поддержку виртуализации лучше выключить. Правда, что это как то влияет ан производительность? Да. OOB и прочее. http://forum.nag.ru/forum/index.php?showtopic=86243&view=findpost&p=854847 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 14 октября, 2013 · Жалоба Слышал, что для роутинга (сервера доступа) в BIOS'е поддержку виртуализации лучше выключить. Правда, что это как то влияет ан производительность? Да. OOB и прочее. http://forum.nag.ru/forum/index.php?showtopic=86243&view=findpost&p=854847 А OOB что такое?) Можно какое-то предписание получить, списочек небольшой) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ilya Evseev Опубликовано 14 октября, 2013 · Жалоба А OOB что такое?) http://en.wikipedia.org/wiki/Out-of-band_management Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 14 октября, 2013 · Жалоба http://en.wikipedia.org/wiki/Out-of-band_management А зачем его выкашивать то? У меня когда-то чудеса давал IPMI-драйвер на старом супермикровском сервере(под 775ый сокет), обеспечивая 100% загрузку 1 ядра при любом трафике. И это при том, что физически IPMI-платы в сервере не было :) Но это явно баг древнего федоровского дистрибутива, больше подобного свинства не встречал. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 15 октября, 2013 (изменено) · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 22 октября, 2013 (изменено) · Жалоба Сервер из предыдущего сообщения... Переделал шейпер 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 22 октября, 2013 · Жалоба iptables у вас основную нагрузку создает, поиск по таблицам. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 23 октября, 2013 · Жалоба Про iptables все понятно, туда еще не добрался для оптимизаций. Я ожидал, что после замены HTB на HFSC нагрузка станет меньше, но этого не произошло. Даже если сделать HFSC+pfifo нагрузка возрастает. Надо еще тестировать этот шейпер, посмотрю как он ограничивает скорость. В целом считаю чтение этой темы очень полезным. Мне удалось снизить нагрузку на процессор на 10% не оптимизируя iptables и не меняя параметров NAPI (сейчас стоит rx-usecs=1, это "low latency" режим для ixgbe). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 28 октября, 2013 · Жалоба У меня когда-то чудеса давал IPMI-драйвер на старом супермикровском сервере У меня в gentoo такое тоже было, вылечилось выбрасыванием ненужного модуля. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 29 октября, 2013 (изменено) · Жалоба Вот с нагрузкой на 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tawer Опубликовано 29 октября, 2013 (изменено) · Жалоба господа, присоветуйте: есть машинка, далеко не топ, но стоит в продакшене на достаточно ответственном участке конфиг: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 29 октября, 2013 · Жалоба если у вас rx missed errors, то есть смысл rx буфер увеличить до максимума Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 29 октября, 2013 · Жалоба IMHO все зло во включенном HT, прерывания прибиты не к физическим ядрам. Потому и загрузка не растет выше 50%, и потери начинаются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tawer Опубликовано 29 октября, 2013 (изменено) · Жалоба если у вас rx missed errors, то есть смысл rx буфер увеличить до максимума имеете ввиду Ring? IMHO все зло во включенном HT, прерывания прибиты не к физическим ядрам. Потому и загрузка не растет выше 50%, и потери начинаются. сам этим фактом не доволен, но, исторически сложилось так, а лишний раз перезагружать рутер для отключения фичи не получится.. (в смысле производить придется разом комплекс мероприятий при минимальном даунтайме, вот решил посоветоваться..) Изменено 29 октября, 2013 пользователем tawer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 29 октября, 2013 · Жалоба Тогда хотя бы посмотрите, какие ядра физические, и прибейте к ним прерывания... И да, ядро какбы того... обновить что ли. В свежих как минимум BKL выпилили. Да и выпиливание route cache, поговаривают, шибко прирост производительности дало... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 30 октября, 2013 · Жалоба выпиливание route cache, поговаривают, шибко прирост производительности дало... Тут сильно зависит. Я "чуда" не заметил вообще, в частности по 2 причинам - route cache hash table был увеличен по сравнению с дефолтом, трафик был достаточно "хороший" для кеширования. Например на NAT с лимитом в 1М трансляций кешировать больше 2М маршрутов явно не надо. А вот прямая зависимость производительности от размера таблицы маршрутизации ощущается очень хорошо. Жалобы на route cache в lkml попадались только, если склероз не изменяет, в плане "web сервер под ддосом" и что производительность кеша зависит от внешних факторов (непредсказуема в общем случае и подвержена dos), в отличии от, собтвенно, таблицы маршрутизации. В процессе выпиливания были даже ядра, которые сами выключали кеш если, по их мнению, трафик шел "плохой". Было очень весело поймать эту фичу на роутере, когда он перешел в "предсказуемый режим черепахи" и просто помер под нагрузкой. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 30 октября, 2013 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tamahome Опубликовано 6 ноября, 2013 · Жалоба Кто подскажет, куда копать для оптимизации? 8.61% [kernel] [k] fib_table_lookup Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 6 ноября, 2013 · Жалоба Интересует вопрос. При выборе процессора на форвардинг (плюс терминация VPN) стоит ли учитывать модель процессора (Intel Core 2 Quad, i5, i7, Xeon и т.д.) или в первую очередь нужно ориентироваться на количество ядер и тактовую частоту для обработки прерываний? Если да, то из каких соображений. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 6 ноября, 2013 · Жалоба При выборе процессора на форвардинг (плюс терминация VPN) стоит ли учитывать модель процессора (Intel Core 2 Quad, i5, i7, Xeon и т.д.) или в первую очередь нужно ориентироваться на количество ядер и тактовую частоту для обработки прерываний? Ессно надо смотреть на семейство. Ориентир - минимальная латентность кешей/памяти и производительность ядра. Ну и ядра с гигагерцами ессно тоже не помешают, но при прочих равных - даже в среднепотолочной вычислительной нагрузке модный некогда Е8500 где-то на уровне целерона G1610-1620. На роутинге - думается, у старых процов будет все еще печальнее. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...