Antares Опубликовано 27 ноября, 2014 · Жалоба Спасибо nuclear cat за идею с отладкой cache miss. Нагрузку снизил вдвое, с 22% до 10%. Починило вот это - полное отключение route кэша: sysctl -w net.ipv4.rt_cache_rebuild_count=-1 Так что те, кто рекомендовал ядра 3.6+ были правы, там выпилен route cache глобально и такой проблемы бы не возникло. Что и требовалось доказать. ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 27 ноября, 2014 · Жалоба Antares, но ведь удалось обойти без апгрейда ведра и даунтайма - это важно =) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Antares Опубликовано 27 ноября, 2014 · Жалоба Antares, но ведь удалось обойти без апгрейда ведра и даунтайма - это важно =) Ядро можно было скомпилить заранее и ночь ребутнуть с ним, даунтайм был бы минимальным Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 27 ноября, 2014 · Жалоба Antares, но ведь удалось обойти без апгрейда ведра и даунтайма - это важно =) Ядро можно было скомпилить заранее и ночь ребутнуть с ним, даунтайм был бы минимальным Чтобы что-то делать - надо быть полностью уверенным :) Вот теперь я полностью уверен, что если что-то будет тупить, надо обновлять ядро, ибо даже с отключенным route кэшем могут быть траблы для ядер младше 3.8. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 12 января, 2019 · Жалоба Такая же проблема, использую 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 из ядра выпилен Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 января, 2019 · Жалоба @Bushi Покажите perf top Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 12 января, 2019 · Жалоба Подумаю как это сделать. В vyos perf отсутствует, попробую доустановить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 12 января, 2019 · Жалоба ethtool -k есть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 12 января, 2019 · Жалоба Да, есть 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] Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба Установил perf, в топе ___bpf_prog_run. Что это может быть? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 января, 2019 · Жалоба https://www.memsql.com/blog/bpf-linux-performance/ Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба не могу понять, как bpf_prog_run связан с трафиком Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 15 января, 2019 · Жалоба что за юзерспейс сервисы крутятся? в файрволе есть хитрый матчинг? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба фаервол простой, отключал его полностью - никак не повлияло на нагрузку в userspace - frr (bgpd,ospfd,zebra), нагрузку на CPU создают практически нулевую Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба Искал, что может использовать bfd, и вспомнил, что у меня работает демон lldpd, отключил, нагрузка на CPU упала в два раза. Для гигабита трафика нагрузка 16% для E31220 3.10GHz нормально или многовато (все ядра нагружены равномерно)? Есть смысл искать проблему дальше? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 января, 2019 · Жалоба 15 минут назад, Bushi сказал: Для гигабита трафика нагрузка 16% для E31220 3.10GHz нормально или многовато (все ядра нагружены равномерно)? Есть смысл искать проблему дальше? Все еще много. Среднестатистически 1Gbit/s на 1 ГГц, то есть загрузка должна быть в районе 8%, если речь только о пропуске (L3) или отдаче (http), без доп.функционалов. Выкладывайте полный perf top в теге кодf, будем дальше смотреть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба Отключение фаервола и nat незначительно уменьшает нагрузку Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 января, 2019 · Жалоба 18 минут назад, Bushi сказал: ipt_to_table это видимо iptables? Да. Что у вас в них? Сколько правил вообще? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба 10 минут назад, jffulcrum сказал: Да. Что у вас в них? Сколько правил вообще? Три десятка, но при сбросе правил нагрузка на ЦПУ меняется незначительно, а ipt_to_table исчезает из perf top. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 января, 2019 · Жалоба 10 минут назад, Bushi сказал: а ipt_to_table исчезает из perf top. А что выходит в топ, и с каким уровнем? Из показанного - mwait_idle_with_hints обычно признак кривых драйверов уровня ядра, что конкретно - это уже в дебаггере надо разбирать. Чаще всего или драйверы сети, или дискового контроллера. В норме это даже в топ-40 вылезать не должно. Остальное все вполне законно кушает свое. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба Да, в верхних строчках остается mwait_idle_with_hints и ixgbe_poll Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
jffulcrum Опубликовано 15 января, 2019 · Жалоба Кстати, софтовые RAID Intel при перестроении массивов генерят много mwait_idle_with_hints Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Bushi Опубликовано 15 января, 2019 · Жалоба Там нет RAID, да и дисковой нагрузки тоже нет, железка используется только как роутер, причем нагрузка на CPU прямо пропорциональна PPS, значит, кривые драйвера? И сыпятся такие сообщения в журнал, откуда они, непонятно, после сброса iptables сообщения больше не появляются kernel: [ 6470.778292] nfnetlink_queue: nf_queue: full at 0 entries, dropping packets(s) Удалил из iptables helpers, сообщения пропали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
anix Опубликовано 16 января, 2019 · Жалоба 9 часов назад, Bushi сказал: Удалил из iptables helpers, сообщения пропали. модуль conntrack не загружен (может может быть загружен даже если правил активных сейчас нет)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...