Перейти к содержимому
Калькуляторы

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

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

sysctl -w net.ipv4.rt_cache_rebuild_count=-1

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Такая же проблема, использую 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 из ядра выпилен

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Да, есть

 

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]

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
15 минут назад, Bushi сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
18 минут назад, Bushi сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 минут назад, jffulcrum сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
10 минут назад, Bushi сказал:

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах
9 часов назад, Bushi сказал:

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас