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

Неоправданно большая нагрузка по system interrupts на мощный софт роутер Буду благодарен за помощь

Спасибо nuclear cat за идею с отладкой cache miss. Нагрузку снизил вдвое, с 22% до 10%. Починило вот это - полное отключение route кэша:

sysctl -w net.ipv4.rt_cache_rebuild_count=-1

 

Так что те, кто рекомендовал ядра 3.6+ были правы, там выпилен route cache глобально и такой проблемы бы не возникло.

Что и требовалось доказать. )))

Share this post


Link to post
Share on other sites

Antares, но ведь удалось обойти без апгрейда ведра и даунтайма - это важно =)

Ядро можно было скомпилить заранее и ночь ребутнуть с ним, даунтайм был бы минимальным

Share this post


Link to post
Share on other sites

Antares, но ведь удалось обойти без апгрейда ведра и даунтайма - это важно =)

Ядро можно было скомпилить заранее и ночь ребутнуть с ним, даунтайм был бы минимальным

 

Чтобы что-то делать - надо быть полностью уверенным :) Вот теперь я полностью уверен, что если что-то будет тупить, надо обновлять ядро, ибо даже с отключенным route кэшем могут быть траблы для ядер младше 3.8.

Share this post


Link to post
Share on other sites

Такая же проблема, использую vyos 1.2 (ядро 4.19.4, процессор Xeon E31220 3.10GHz, карточка intel 82599ES), при трафике менее 1 Gbps software interrupt съедают почти треть процессора. Очереди распределены по 4-м ядрам

 

cat /proc/interrupts | grep eth
 36:  946513803          0          1          0   PCI-MSI 1050624-edge      eth2-TxRx-0
 37:          0  873622930          0          1   PCI-MSI 1050625-edge      eth2-TxRx-1
 38:          1          0  871086890          0   PCI-MSI 1050626-edge      eth2-TxRx-2
 39:          0          1          0  858968022   PCI-MSI 1050627-edge      eth2-TxRx-3
 40:          0          0      11684          0   PCI-MSI 1050628-edge      eth2

route cache из ядра выпилен

Share this post


Link to post
Share on other sites

Подумаю как это сделать. В vyos perf отсутствует, попробую доустановить.

Share this post


Link to post
Share on other sites

Да, есть

 

rx-checksumming: on
tx-checksumming: on
	tx-checksum-ipv4: off [fixed]
	tx-checksum-ip-generic: on
	tx-checksum-ipv6: off [fixed]
	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: on
	tx-tcp-segmentation: on
	tx-tcp-ecn-segmentation: off [fixed]
	tx-tcp-mangleid-segmentation: off
	tx-tcp6-segmentation: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
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
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: on
tx-gre-csum-segmentation: on
tx-ipxip4-segmentation: on
tx-ipxip6-segmentation: on
tx-udp_tnl-segmentation: on
tx-udp_tnl-csum-segmentation: on
tx-gso-partial: on
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: on
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off [fixed]
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off
hw-tc-offload: off
esp-hw-offload: on
esp-tx-csum-hw-offload: on
rx-udp_tunnel-port-offload: on
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

 

Share this post


Link to post
Share on other sites

Установил perf, в топе ___bpf_prog_run. Что это может быть?

Share this post


Link to post
Share on other sites

не могу понять, как bpf_prog_run связан с трафиком

Share this post


Link to post
Share on other sites

что за юзерспейс сервисы крутятся? в файрволе есть хитрый матчинг?

Share this post


Link to post
Share on other sites

фаервол простой, отключал его полностью - никак не повлияло на нагрузку

в userspace - frr (bgpd,ospfd,zebra), нагрузку на CPU создают практически нулевую

Share this post


Link to post
Share on other sites

Искал, что может использовать bfd, и вспомнил, что у меня работает демон lldpd, отключил, нагрузка на CPU упала в два раза.

 

Для гигабита трафика нагрузка 16% для E31220 3.10GHz нормально или многовато (все ядра нагружены равномерно)? Есть смысл искать проблему дальше?

Share this post


Link to post
Share on other sites
15 минут назад, Bushi сказал:

Для гигабита трафика нагрузка 16% для E31220 3.10GHz нормально или многовато (все ядра нагружены равномерно)? Есть смысл искать проблему дальше?

Все еще много. Среднестатистически 1Gbit/s на 1 ГГц, то есть загрузка должна быть в районе 8%,  если речь только о пропуске (L3) или отдаче (http), без доп.функционалов. Выкладывайте полный perf top в теге кодf, будем дальше смотреть.

Share this post


Link to post
Share on other sites

ipt_to_table это видимо iptables?

 

  12.53%  [kernel]            [k] ipt_do_table
   6.56%  [kernel]            [k] mwait_idle_with_hints.constprop.3
   4.54%  [kernel]            [k] ixgbe_poll
   2.88%  [kernel]            [k] hash_net4_test
   2.42%  [kernel]            [k] fib_table_lookup
   2.40%  [kernel]            [k] set_match_v3
   2.37%  [kernel]            [k] __entry_SYSCALL_64_trampoline
   2.08%  [kernel]            [k] menu_select
   2.03%  [kernel]            [k] jhash2
   2.01%  [kernel]            [k] ixgbe_xmit_frame_ring
   1.89%  [kernel]            [k] cpuidle_enter_state
   1.63%  [kernel]            [k] native_irq_return_iret
   1.48%  [kernel]            [k] ip_forward
   1.42%  [kernel]            [k] hash_net4_kadt
   1.31%  [kernel]            [k] __dev_queue_xmit
   1.26%  [kernel]            [k] bond_start_xmit
   1.21%  [kernel]            [k] pfifo_fast_dequeue
   1.20%  [kernel]            [k] swiotlb_sync_single_for_device
   1.02%  [kernel]            [k] ip_route_input_slow
   1.01%  [kernel]            [k] tcp_mt
   1.00%  [kernel]            [k] arch_local_irq_enable
   0.99%  [kernel]            [k] ipv4_conntrack_defrag
   0.95%  [kernel]            [k] native_sched_clock
   0.82%  [kernel]            [k] timekeeping_get_ns
   0.81%  [kernel]            [k] ip_rcv_core.isra.14
   0.81%  [kernel]            [k] eth_header
   0.80%  [kernel]            [k] __softirqentry_text_start
   0.76%  [kernel]            [k] dev_gro_receive
   0.72%  [kernel]            [k] map_id_range_down
   0.69%  [kernel]            [k] net_rx_action
   0.69%  [kernel]            [k] bond_handle_frame
   0.67%  [kernel]            [k] __local_bh_enable_ip
   0.67%  [kernel]            [k] swiotlb_sync_single

 

 

 

 

Share this post


Link to post
Share on other sites

Отключение фаервола и nat незначительно уменьшает нагрузку

Share this post


Link to post
Share on other sites
18 минут назад, Bushi сказал:

ipt_to_table это видимо iptables? 

Да. Что у вас в них? Сколько правил вообще?

Share this post


Link to post
Share on other sites
10 минут назад, jffulcrum сказал:

Да. Что у вас в них? Сколько правил вообще?

Три десятка, но при сбросе правил нагрузка на ЦПУ меняется незначительно, а ipt_to_table исчезает из perf top.

Share this post


Link to post
Share on other sites
10 минут назад, Bushi сказал:

а ipt_to_table исчезает из perf top.

А что выходит в топ, и с каким уровнем? Из показанного - mwait_idle_with_hints обычно признак кривых драйверов уровня ядра, что конкретно - это уже в дебаггере надо разбирать. Чаще всего или драйверы сети, или дискового контроллера. В норме это даже в топ-40 вылезать не должно. Остальное все вполне законно кушает свое.

 

Share this post


Link to post
Share on other sites

Да, в верхних строчках остается mwait_idle_with_hints и ixgbe_poll

Share this post


Link to post
Share on other sites

Кстати, софтовые RAID Intel при перестроении массивов генерят много mwait_idle_with_hints 

Share this post


Link to post
Share on other sites

Там нет RAID, да и дисковой нагрузки тоже нет, железка используется только как роутер, причем нагрузка на CPU прямо пропорциональна PPS, значит, кривые драйвера?

 

И сыпятся такие сообщения в журнал, откуда они, непонятно, после сброса iptables сообщения больше не появляются

 

kernel: [ 6470.778292] nfnetlink_queue: nf_queue: full at 0 entries, dropping packets(s)

Удалил из iptables helpers, сообщения пропали.

Share this post


Link to post
Share on other sites
9 часов назад, Bushi сказал:

Удалил из iptables helpers, сообщения пропали.

модуль conntrack не загружен (может может быть загружен даже если правил активных сейчас нет)?

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