tartila Опубликовано 29 июня, 2015 (изменено) · Жалоба Господа, прошу подтолкнуть в верном направлении. Имеется прозрачный шейпер на Linux 3.4.11 (самосбор) на RHEL 6, основанный на бридже из двух портов - eth0 и eth1. На этот бридж навешиваю HTB 10k правил /32, упакованные хэшом, а если быть более точным - навешиваю на eth0 и eth1, понятно, по каким соображениям. Раньше такие шейперы у меня молотили 1G-2G без всяких проблем. Теперь же пришло время и я ушел на 10G - Intel X520, драйвер с сайта intel последний 4.1. Прерывания очередей раскиданы по каждому ядру, первая очередь eth0 = первой очереди eth1 и т.д. Ядер 16, без HT - машина на E2960, clocksource = hpet. Так вот тут наблюдаю странную картину. Шейпер работает идеально до определенного уровня трафика - ~ 2,5/2 Gb/s, соответственно около 700 kPPS на интерфейс по входу и выходу (прикинул на калькуляторе, пока не рисовал график). Что значит - работает идеально? Через этот шейпер ходит машина, для которой нет правил на шейпере. То есть, она просто проходит бридж. В момент пересечения указанного порога пинг подскакивает до 100 ms для этой машины. На самом шейпере видим лавинообразный рост ksoftirq от всех очередей на всех ядрах, итого в определенный момент все 16 ядер погружены в 100% si. Еще 15 минут назад на трафике нииже на 100-150 Mb/s загрузка машины составляла около 3-4% (также по si), и вот трафик перешагнул невидимый барьер и сразу имеем все процессора в полке. Отключаю HTB, оставляя только бридж и загрузка сразу падает до 3-4%, пинг стабилизируется - проблем нет. Сгружаю трафик обратно на 1G шейпера и там он растекается без особых проблем - повторял пару раз. Корневой класс HTB, конечно же 10G quantum 1500. MTU 1500 - не могу использовать jumbo, ибо угрохаю cat4900m внизу. :) Теперь мои мысли - думается мне, я вляпался в проблему HTB и точности clocksource. То есть, до определенных kPPS x объем hash все в порядке, пока хватает частоты HPET. А вот потом - все плохо. Отчасти это подтверждает clocksource = tsc, при котором становится чуть лучше - загрузка уже 60-70%, но машине все также плохо. Собственно, - вопрос, что делать и кто виноват? :) --- Решение: добиться в текущий момент шейпирования на многопроцессорной платформе НЕ представляется возможным, несмотря на кажущийся выход в виде дисциплины mq. Тем не менее, проблему можно решить с помощью дисциплины ingress и отказа от шейпирования в пользу полисинга. Всем спасибо за помощь! Изменено 10 августа, 2015 пользователем tartila Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 29 июня, 2015 · Жалоба perf top? Как вообще ваши X520 переносят входящий PPS в районе 1-2M? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 29 июня, 2015 · Жалоба perf top? Как вообще ваши X520 переносят входящий PPS в районе 1-2M? Сейчас буду мастрячить как раз perf. Переносят абсолютно нормально - в шапке написано, что "отключаю HTB" и все OK. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 29 июня, 2015 · Жалоба И так, собрал немного данных, но прояснения это не дало. perf top до появления эффекта: CPU ~ 10% si ----------------------------------------------------- | TX port1: 361166 pkts/s RX port1: 273573 pkts/s | TX port2: 273735 pkts/s RX port2: 360481 pkts/s ----------------------------------------------------- PerfTop: 13230 irqs/sec kernel:99.9% exact: 0.0% [1000Hz cycles], (all, 16 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------------------- 40.90% [kernel] [k] _raw_spin_lock 4.89% [ixgbe] [k] ixgbe_poll 4.39% [kernel] [k] htb_dequeue 3.72% [kernel] [k] u32_classify 2.63% [kernel] [k] _raw_read_lock_bh 2.34% [ixgbe] [k] ixgbe_xmit_frame_ring 1.98% [kernel] [k] irq_entries_start 1.68% [kernel] [k] delay_tsc 1.51% [kernel] [k] htb_enqueue 1.42% [kernel] [k] dev_queue_xmit 1.24% [kernel] [k] net_tx_action 1.18% [kernel] [k] qdisc_dequeue_head 1.18% [kernel] [k] htb_activate_prios 1.15% [kernel] [k] __alloc_skb 1.07% [kernel] [k] dma_issue_pending_all 1.00% [kernel] [k] _raw_spin_trylock 0.95% [kernel] [k] __napi_complete 0.86% [kernel] [k] add_interrupt_randomness 0.84% [kernel] [k] br_fdb_update 0.78% [kernel] [k] ioat2_issue_pending 0.74% [kernel] [k] htb_add_to_wait_tree 0.74% [kernel] [k] put_page 0.72% [kernel] [k] htb_lookup_leaf 0.64% [kernel] [k] rb_erase 0.62% [kernel] [k] skb_release_data 0.62% [kernel] [k] ebt_do_table 0.54% [ixgbe] [k] ixgbe_read_reg 0.53% [kernel] [k] _raw_read_unlock_bh 0.45% [kernel] [k] consume_skb 0.45% [kernel] [k] get_nohz_timer_target 0.45% [kernel] [k] __do_softirq 0.45% [kernel] [k] apic_timer_interrupt 0.43% [kernel] [k] rb_insert_color 0.43% [kernel] [k] sch_direct_xmit 0.41% [kernel] [k] __qdisc_run 0.40% [kernel] [k] _raw_spin_lock_irqsave 0.40% [kernel] [k] local_bh_enable_ip 0.40% [kernel] [k] nf_iterate 0.38% [kernel] [k] pfifo_enqueue 0.36% [kernel] [k] __netif_receive_skb 0.35% [kernel] [k] dql_completed 0.35% [kernel] [k] rb_first 0.33% [kernel] [k] dev_gro_receive 0.29% [kernel] [k] kfree 0.28% [kernel] [k] __kmalloc 0.25% [kernel] [k] find_busiest_group 0.25% [kernel] [k] memcpy 0.25% [kernel] [k] br_nf_pre_routing 0.23% [kernel] [k] htb_deactivate_prios 0.23% [kernel] [k] rcu_idle_enter_common 0.23% [kernel] [k] __hrtimer_start_range_ns 0.22% [kernel] [k] br_handle_frame 0.21% [kernel] [k] rcu_idle_exit_common 0.21% [kernel] [k] read_tsc 0.21% [ixgbe] [k] ixgbe_msix_clean_rings 0.20% [kernel] [k] hrtimer_interrupt 0.20% [kernel] [k] kmem_cache_free perf top в момент эффекта залипания CPU ~ 100% si ----------------------------------------------------- | TX port1: 437415 pkts/s RX port1: 341264 pkts/s | TX port2: 329385 pkts/s RX port2: 436173 pkts/s ----------------------------------------------------- PerfTop: 14262 irqs/sec kernel:100.0% exact: 0.0% [1000Hz cycles], (all, 16 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------------------- 79.88% [kernel] [k] _raw_spin_lock 2.09% [kernel] [k] htb_dequeue 1.70% [kernel] [k] u32_classify 1.32% [kernel] [k] _raw_read_lock_bh 1.12% [kernel] [k] htb_activate_prios 1.05% [ixgbe] [k] ixgbe_poll 0.94% [kernel] [k] dev_queue_xmit 0.91% [kernel] [k] __alloc_skb 0.85% [kernel] [k] delay_tsc 0.82% [ixgbe] [k] ixgbe_xmit_frame_ring 0.72% [kernel] [k] htb_enqueue 0.64% [kernel] [k] qdisc_dequeue_head 0.39% [kernel] [k] br_fdb_update 0.34% [kernel] [k] put_page 0.28% [kernel] [k] ebt_do_table 0.27% [kernel] [k] sch_direct_xmit 0.27% [kernel] [k] consume_skb 0.26% [kernel] [k] skb_release_data 0.25% [kernel] [k] rb_erase 0.24% [ixgbe] [k] ixgbe_read_reg 0.23% [kernel] [k] _raw_read_unlock_bh 0.23% [kernel] [k] napi_gro_receive 0.22% [kernel] [k] rb_insert_color 0.22% [kernel] [k] __kmalloc 0.21% [kernel] [k] htb_lookup_leaf 0.19% [kernel] [k] htb_add_to_wait_tree 0.19% [kernel] [k] local_bh_enable_ip 0.19% [kernel] [k] __qdisc_run 0.17% [kernel] [k] nf_iterate 0.16% [kernel] [k] kfree 0.16% [kernel] [k] pfifo_enqueue 0.15% [kernel] [k] memcpy 0.14% [kernel] [k] __netif_receive_skb 0.10% [kernel] [k] htb_deactivate_prios 0.09% [kernel] [k] eth_type_trans 0.09% [kernel] [k] dev_gro_receive 0.09% [kernel] [k] inet_gro_receive 0.09% [kernel] [k] br_nf_pre_routing 0.09% [kernel] [k] irq_entries_start 0.08% [kernel] [k] kmem_cache_free 0.08% [kernel] [k] kmem_cache_alloc 0.08% [ixgbe] [k] ixgbe_alloc_rx_buffers 0.08% [kernel] [k] __napi_complete 0.08% [kernel] [k] br_handle_frame 0.07% [kernel] [k] rb_next 0.07% [kernel] [k] swiotlb_map_page 0.06% [kernel] [k] __br_fdb_get 0.06% [kernel] [k] br_nf_post_routing 0.06% [kernel] [k] rb_first 0.06% [kernel] [k] skb_release_head_state 0.06% [kernel] [k] tcp_gro_receive 0.06% [kernel] [k] htb_change_class_mode 0.06% [kernel] [k] ksize 0.05% [kernel] [k] __rb_rotate_left 0.05% [kernel] [k] br_nf_forward_ip 0.05% [kernel] [k] nf_hook_slow 0.05% [kernel] [k] free_block perf top в проблемный момент, но с выключенным шейпером (трафик идет без увеличения задержки): CPU ~ 6% si ----------------------------------------------------- | TX port1: 452130 pkts/s RX port1: 342013 pkts/s | TX port2: 344151 pkts/s RX port2: 454848 pkts/s ----------------------------------------------------- PerfTop: 14315 irqs/sec kernel:99.9% exact: 0.0% [1000Hz cycles], (all, 16 CPUs) ------------------------------------------------------------------------------------------------------------------------------------------------------------- 74.09% [kernel] [k] _raw_spin_lock 2.49% [kernel] [k] htb_dequeue 2.10% [kernel] [k] u32_classify 1.62% [ixgbe] [k] ixgbe_poll 1.54% [kernel] [k] _raw_read_lock_bh 1.35% [kernel] [k] htb_activate_prios 1.09% [ixgbe] [k] ixgbe_xmit_frame_ring 1.06% [kernel] [k] delay_tsc 1.01% [kernel] [k] __alloc_skb 1.00% [kernel] [k] dev_queue_xmit 0.88% [kernel] [k] htb_enqueue 0.76% [kernel] [k] qdisc_dequeue_head 0.48% [kernel] [k] br_fdb_update 0.39% [kernel] [k] put_page 0.36% [kernel] [k] skb_release_data 0.34% [kernel] [k] ebt_do_table 0.33% [kernel] [k] irq_entries_start 0.32% [kernel] [k] rb_erase 0.31% [kernel] [k] htb_lookup_leaf 0.30% [kernel] [k] _raw_read_unlock_bh 0.30% [kernel] [k] sch_direct_xmit 0.30% [kernel] [k] consume_skb 0.29% [ixgbe] [k] ixgbe_read_reg 0.28% [kernel] [k] __napi_complete 0.27% [kernel] [k] rb_insert_color 0.26% [kernel] [k] htb_add_to_wait_tree 0.25% [kernel] [k] __kmalloc 0.24% [kernel] [k] local_bh_enable_ip 0.23% [kernel] [k] nf_iterate 0.21% [kernel] [k] pfifo_enqueue 0.19% [kernel] [k] __qdisc_run 0.18% [kernel] [k] __netif_receive_skb 0.17% [kernel] [k] kfree 0.15% [kernel] [k] dev_gro_receive 0.15% [kernel] [k] napi_gro_receive 0.15% [kernel] [k] add_interrupt_randomness 0.15% [kernel] [k] dma_issue_pending_all 0.14% [kernel] [k] memcpy 0.12% [kernel] [k] htb_deactivate_prios 0.12% [kernel] [k] kmem_cache_free 0.12% [kernel] [k] eth_type_trans 0.11% [kernel] [k] br_handle_frame 0.11% [kernel] [k] inet_gro_receive 0.11% [kernel] [k] br_nf_pre_routing 0.11% [kernel] [k] kmem_cache_alloc 0.11% [kernel] [k] ioat2_issue_pending 0.09% [ixgbe] [k] ixgbe_alloc_rx_buffers 0.09% [kernel] [k] rb_first 0.09% [kernel] [k] rb_next 0.08% [kernel] [k] swiotlb_map_page 0.08% [kernel] [k] nf_hook_slow 0.08% [kernel] [k] __rb_rotate_left 0.07% [kernel] [k] dql_completed 0.07% [ixgbe] [k] __kc_netdev_pick_tx 0.07% [kernel] [k] br_nf_forward_ip 0.07% [kernel] [k] net_tx_action 0.06% [kernel] [k] br_nf_post_routing Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 июня, 2015 · Жалоба Лучше спросить у разработчиков в рассылке linux-netdev: http://vger.kernel.org/vger-lists.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 30 июня, 2015 · Жалоба С архаичным ядром и сборкой RHEL - боюсь они отправят погулять, точнее апгрейдить ядро Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 30 июня, 2015 · Жалоба Это да, еще не мешало бы call graph для самого прожорливого _raw_spin_lock сделать, как показано здесь: http://www.brendangregg.com/perf.html Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 1 июля, 2015 · Жалоба А если сделать quantum 15000? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 1 июля, 2015 · Жалоба А лучше 65000. Откуда вы берете это 1500? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
SABRE Опубликовано 1 июля, 2015 · Жалоба kayot Как откуда?! Если КАМАЗ чайными ложками отгружать, то 100% точнее выходит. Нужно только очень быстро этой ложкой орудовать. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 1 июля, 2015 · Жалоба Это у меня в sc по умолчанию quantum 1500 стоит. На гигабитных каналах увеличивать не приходилось. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 14 июля, 2015 · Жалоба И так, провел кучу оптимизаций... Что имею в grub.conf - iommu=soft processor.max_cstate=0 intel_idle.max_cstate=0 idle=poll. В момент, когда более или менее все OK. Shaper quality - отношение реальной скорости (на тестовый сервер) к скорости в шейпере в процентах. Clocksource = tsc TX port1: 313761 pkts/s RX port1: 247093 pkts/s TX port2: 246953 pkts/s RX port2: 312300 pkts/s CPU load = 1.4%, CPU Interrupts = 0.9% rtt min/avg/max/mdev = 0.073/0.216/2.281/0.132 ms Shaper quality = 99.4524% # Overhead Command Shared Object Symbol # ........ ............... ........................ .............................................. # 77.02% swapper [kernel.kallsyms] [k] cpu_startup_entry 3.32% swapper [kernel.kallsyms] [k] _raw_spin_lock 2.04% swapper [kernel.kallsyms] [k] delay_tsc 1.07% swapper [kernel.kallsyms] [k] memcpy 1.05% swapper [kernel.kallsyms] [k] htb_dequeue 1.03% swapper [ixgbe] [k] ixgbe_poll 0.90% swapper [kernel.kallsyms] [k] _raw_read_lock_bh 0.80% swapper [ixgbe] [k] ixgbe_read_reg 0.63% swapper [ixgbe] [k] ixgbe_clean_rx_irq 0.53% swapper [ixgbe] [k] ixgbe_xmit_frame_ring 0.49% swapper [kernel.kallsyms] [k] qdisc_dequeue_head 0.47% swapper [kernel.kallsyms] [k] u32_classify 0.43% swapper [kernel.kallsyms] [k] put_page 0.39% swapper [kernel.kallsyms] [k] irq_entries_start 0.37% swapper [kernel.kallsyms] [k] __dev_queue_xmit 0.36% swapper [kernel.kallsyms] [k] htb_activate_prios 0.34% swapper [kernel.kallsyms] [k] tick_nohz_stop_sched_tick 0.33% swapper [kernel.kallsyms] [k] __build_skb 0.27% swapper [kernel.kallsyms] [k] br_fdb_update 0.26% swapper [kernel.kallsyms] [k] put_compound_page 0.26% swapper [kernel.kallsyms] [k] htb_add_to_wait_tree 0.23% swapper [kernel.kallsyms] [k] skb_release_data 0.22% swapper [kernel.kallsyms] [k] ebt_do_table 0.22% swapper [kernel.kallsyms] [k] htb_enqueue 0.21% swapper [kernel.kallsyms] [k] _raw_read_unlock_bh 0.20% swapper [kernel.kallsyms] [k] rb_erase 0.20% swapper [kernel.kallsyms] [k] consume_skb 0.20% swapper [kernel.kallsyms] [k] __napi_complete 0.19% swapper [kernel.kallsyms] [k] nf_iterate 0.18% swapper [kernel.kallsyms] [k] kmem_cache_alloc 0.18% swapper [kernel.kallsyms] [k] build_skb 0.16% swapper [kernel.kallsyms] [k] lapic_next_deadline 0.15% swapper [kernel.kallsyms] [k] rb_insert_color 0.15% swapper [kernel.kallsyms] [k] __local_bh_enable_ip 0.14% swapper [kernel.kallsyms] [k] htb_lookup_leaf 0.14% swapper [kernel.kallsyms] [k] dql_completed 0.14% swapper [kernel.kallsyms] [k] pfifo_enqueue 0.12% swapper [kernel.kallsyms] [k] rb_first 0.12% swapper [kernel.kallsyms] [k] skb_free_head 0.12% swapper [kernel.kallsyms] [k] __qdisc_run 0.10% swapper [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.10% swapper [ixgbe] [k] ixgbe_msix_clean_rings 0.10% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.09% swapper [kernel.kallsyms] [k] __netif_receive_skb_core 0.08% swapper [kernel.kallsyms] [k] eth_type_trans 0.07% swapper [kernel.kallsyms] [k] __do_softirq 0.07% swapper [kernel.kallsyms] [k] br_nf_pre_routing 0.07% swapper [kernel.kallsyms] [k] br_handle_frame 0.07% swapper [kernel.kallsyms] [k] read_tsc 0.07% swapper [kernel.kallsyms] [k] sch_direct_xmit 0.07% swapper [kernel.kallsyms] [k] netif_receive_skb_internal 0.07% swapper [kernel.kallsyms] [k] ktime_get 0.06% swapper [kernel.kallsyms] [k] hrtimer_interrupt 0.06% swapper [kernel.kallsyms] [k] rcu_eqs_enter_common Когда все плохо... Clocksource = tsc TX port1: 386199 pkts/s RX port1: 307703 pkts/s TX port2: 309489 pkts/s RX port2: 390748 pkts/s CPU load = 0.2%, CPU Interrupts = 0.1% rtt min/avg/max/mdev = 0.118/0.596/3.048/0.350 ms Shaper quality = 37.7413% # Overhead Command Shared Object Symbol # ........ ............... ......................... .............................................. # 72.57% swapper [kernel.kallsyms] [k] cpu_startup_entry 4.71% swapper [kernel.kallsyms] [k] _raw_spin_lock 3.05% swapper [kernel.kallsyms] [k] delay_tsc 1.36% swapper [kernel.kallsyms] [k] memcpy 1.17% swapper [kernel.kallsyms] [k] _raw_read_lock_bh 1.16% swapper [ixgbe] [k] ixgbe_read_reg 1.13% swapper [kernel.kallsyms] [k] htb_dequeue 1.03% swapper [ixgbe] [k] ixgbe_poll 0.76% swapper [kernel.kallsyms] [k] htb_activate_prios 0.74% swapper [ixgbe] [k] ixgbe_clean_rx_irq 0.70% swapper [kernel.kallsyms] [k] qdisc_dequeue_head 0.61% swapper [kernel.kallsyms] [k] u32_classify 0.58% swapper [ixgbe] [k] ixgbe_xmit_frame_ring 0.51% swapper [kernel.kallsyms] [k] put_page 0.47% swapper [kernel.kallsyms] [k] __dev_queue_xmit 0.40% swapper [kernel.kallsyms] [k] __build_skb 0.37% swapper [kernel.kallsyms] [k] irq_entries_start 0.34% swapper [kernel.kallsyms] [k] tick_nohz_stop_sched_tick 0.34% swapper [kernel.kallsyms] [k] br_fdb_update 0.30% swapper [kernel.kallsyms] [k] ebt_do_table 0.30% swapper [kernel.kallsyms] [k] put_compound_page 0.30% swapper [kernel.kallsyms] [k] kmem_cache_alloc 0.29% swapper [kernel.kallsyms] [k] _raw_read_unlock_bh 0.27% swapper [kernel.kallsyms] [k] skb_release_data 0.27% swapper [kernel.kallsyms] [k] htb_enqueue 0.24% swapper [kernel.kallsyms] [k] __napi_complete 0.23% swapper [kernel.kallsyms] [k] nf_iterate 0.23% swapper [kernel.kallsyms] [k] consume_skb 0.18% swapper [kernel.kallsyms] [k] __local_bh_enable_ip 0.18% swapper [kernel.kallsyms] [k] skb_free_head 0.18% swapper [kernel.kallsyms] [k] build_skb 0.17% swapper [kernel.kallsyms] [k] rb_erase 0.16% swapper [kernel.kallsyms] [k] __qdisc_run 0.16% swapper [kernel.kallsyms] [k] rb_insert_color 0.15% swapper [kernel.kallsyms] [k] pfifo_enqueue 0.14% swapper [kernel.kallsyms] [k] dql_completed 0.12% swapper [kernel.kallsyms] [k] htb_lookup_leaf 0.11% swapper [kernel.kallsyms] [k] eth_type_trans 0.10% swapper [ixgbe] [k] ixgbe_msix_clean_rings 0.10% swapper [kernel.kallsyms] [k] netif_receive_skb_internal 0.09% swapper [kernel.kallsyms] [k] __netif_receive_skb_core 0.09% swapper [kernel.kallsyms] [k] sch_direct_xmit 0.09% swapper [kernel.kallsyms] [k] br_nf_pre_routing 0.09% swapper [kernel.kallsyms] [k] htb_add_to_wait_tree 0.09% swapper [kernel.kallsyms] [k] br_handle_frame 0.09% swapper [kernel.kallsyms] [k] skb_add_rx_frag 0.07% swapper [kernel.kallsyms] [k] __netdev_alloc_frag 0.07% swapper [kernel.kallsyms] [k] kmem_cache_free 0.07% swapper [kernel.kallsyms] [k] rb_next 0.06% swapper [kernel.kallsyms] [k] __br_fdb_get 0.06% swapper [kernel.kallsyms] [k] nf_hook_slow 0.06% swapper [kernel.kallsyms] [k] br_nf_post_routing 0.06% swapper [kernel.kallsyms] [k] __netdev_pick_tx 0.06% swapper [kernel.kallsyms] [k] __do_softirq 0.06% kipmi0 [kernel.kallsyms] [k] port_inb 0.05% swapper [kernel.kallsyms] [k] br_nf_forward_ip 0.05% swapper [ixgbe] [k] ixgbe_update_itr 0.05% swapper [kernel.kallsyms] [k] __netif_receive_skb 0.05% swapper [kernel.kallsyms] [k] ktime_get 0.05% swapper [kernel.kallsyms] [k] ksize 0.05% swapper [kernel.kallsyms] [k] rcu_eqs_enter_common 0.05% swapper [kernel.kallsyms] [k] read_tsc 0.05% swapper [kernel.kallsyms] [k] pskb_expand_head 0.05% swapper [kernel.kallsyms] [k] kfree 0.05% swapper [kernel.kallsyms] [k] rb_first 0.05% swapper [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.05% swapper [kernel.kallsyms] [k] get_page_from_freelist 0.05% swapper [kernel.kallsyms] [k] htb_change_class_mode 0.05% swapper [ixgbe] [k] ixgbe_alloc_rx_buffers 0.04% swapper [kernel.kallsyms] [k] skb_release_head_state Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 14 июля, 2015 · Жалоба Забыл добавить, что ядрышко апгрейднул до 3.18.17. Кстати, до включения processor.max_cstate=0 intel_idle.max_cstate=0 idle=poll Clocksource = tsc TX port1: 392857 pkts/s RX port1: 282654 pkts/s TX port2: 282751 pkts/s RX port2: 392924 pkts/s CPU load = 0.6%, CPU Interrupts = 0.4% rtt min/avg/max/mdev = 0.084/0.329/2.096/0.202 ms Shaper quality = 88.6516% # To display the perf.data header info, please use --header/--header-only options. # # Samples: 4M of event 'cycles' # Event count (approx.): 1541745692590 # # Overhead Command Shared Object Symbol # ........ ............... ............................ ......................................................................................................... # 16.89% swapper [kernel.kallsyms] [k] _raw_spin_lock 7.73% swapper [kernel.kallsyms] [k] delay_tsc 5.65% swapper [kernel.kallsyms] [k] mwait_idle 4.62% swapper [kernel.kallsyms] [k] memcpy 3.92% swapper [ixgbe] [k] ixgbe_poll 3.88% swapper [kernel.kallsyms] [k] htb_dequeue 3.54% swapper [kernel.kallsyms] [k] _raw_read_lock_bh 3.48% swapper [ixgbe] [k] ixgbe_read_reg 2.67% swapper [kernel.kallsyms] [k] irq_entries_start 2.64% swapper [ixgbe] [k] ixgbe_clean_rx_irq 2.15% swapper [kernel.kallsyms] [k] qdisc_dequeue_head 2.10% swapper [ixgbe] [k] ixgbe_xmit_frame_ring 1.89% swapper [kernel.kallsyms] [k] htb_activate_prios 1.81% swapper [kernel.kallsyms] [k] put_page 1.71% swapper [kernel.kallsyms] [k] u32_classify 1.42% swapper [kernel.kallsyms] [k] __dev_queue_xmit 1.24% swapper [kernel.kallsyms] [k] __build_skb 1.22% swapper [kernel.kallsyms] [k] tick_nohz_stop_sched_tick 1.13% swapper [kernel.kallsyms] [k] br_fdb_update 1.11% swapper [kernel.kallsyms] [k] put_compound_page 0.90% swapper [kernel.kallsyms] [k] ebt_do_table 0.86% swapper [kernel.kallsyms] [k] _raw_read_unlock_bh 0.85% swapper [kernel.kallsyms] [k] htb_enqueue 0.79% swapper [kernel.kallsyms] [k] skb_release_data 0.79% swapper [kernel.kallsyms] [k] __napi_complete 0.77% swapper [kernel.kallsyms] [k] kmem_cache_alloc 0.75% swapper [kernel.kallsyms] [k] rb_erase 0.72% swapper [kernel.kallsyms] [k] nf_iterate 0.71% swapper [kernel.kallsyms] [k] build_skb 0.63% swapper [kernel.kallsyms] [k] consume_skb 0.61% swapper [kernel.kallsyms] [k] htb_add_to_wait_tree 0.57% swapper [kernel.kallsyms] [k] rb_insert_color 0.56% swapper [kernel.kallsyms] [k] __local_bh_enable_ip 0.56% swapper [kernel.kallsyms] [k] pfifo_enqueue 0.54% swapper [kernel.kallsyms] [k] skb_free_head 0.53% swapper [kernel.kallsyms] [k] __qdisc_run 0.49% swapper [kernel.kallsyms] [k] dql_completed 0.47% swapper [kernel.kallsyms] [k] htb_lookup_leaf 0.43% swapper [ixgbe] [k] ixgbe_msix_clean_rings 0.39% swapper [kernel.kallsyms] [k] rcu_eqs_enter_common 0.38% swapper [kernel.kallsyms] [k] cpu_startup_entry 0.33% swapper [kernel.kallsyms] [k] eth_type_trans 0.32% swapper [kernel.kallsyms] [k] __netif_receive_skb_core 0.31% swapper [kernel.kallsyms] [k] rb_first 0.30% swapper [kernel.kallsyms] [k] lapic_next_deadline 0.28% swapper [kernel.kallsyms] [k] apic_timer_interrupt 0.28% swapper [kernel.kallsyms] [k] skb_add_rx_frag 0.28% swapper [kernel.kallsyms] [k] sch_direct_xmit 0.27% swapper [kernel.kallsyms] [k] br_nf_pre_routing 0.27% swapper [kernel.kallsyms] [k] rcu_eqs_exit_common 0.26% swapper [kernel.kallsyms] [k] br_handle_frame 0.26% swapper [kernel.kallsyms] [k] _raw_spin_lock_irqsave 0.24% swapper [kernel.kallsyms] [k] __br_fdb_get 0.24% swapper [kernel.kallsyms] [k] netif_receive_skb_internal Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
nuclearcat Опубликовано 14 июля, 2015 · Жалоба Мож: echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu4/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu5/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu6/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu7/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu8/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu9/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu10/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu11/cpufreq/scaling_governor ? Проверьте частоту процессора в /proc/cpuinfo, не плавает ли до слишком низкой? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 14 июля, 2015 · Жалоба Я боюсь привет Вам передает какой-то поганый лок в ядре "74.09% [kernel] [k] _raw_spin_lock". Вот это совершенно не нормально, причем, этот лок есть и в "нормальном" и "не нормальном" режимах. Именно он и вызывает такую деградацию, потому что в случае многоядерной машины при росте нагрузки хотя бы в два раза вы проваливаетесь в скорости раз эдак в 16, потому что каждое ядро начинает долбать локи. Я бы попробовал вообще уйти от распределения по всем ядрам и попробовать провернуть это на одном логическом ядре. А потом с помощью, скажем, CPU опции iptables размазал трафик по всем ядрам локально, чтобы избежать блокировок вовсе. Ну и старое ядро на помойку, там столько ужаса, что никакие портеры не запортируют :) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 14 июля, 2015 · Жалоба Я боюсь привет Вам передает какой-то поганый лок в ядре "74.09% [kernel] [k] _raw_spin_lock". Так ушел я от raw_spin_lock - в последних тестах он уже на уровне 5%. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 14 июля, 2015 · Жалоба Мож: echo performance >/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu4/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu5/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu6/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu7/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu8/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu9/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu10/cpufreq/scaling_governor echo performance >/sys/devices/system/cpu/cpu11/cpufreq/scaling_governor ? Проверьте частоту процессора в /proc/cpuinfo, не плавает ли до слишком низкой? Не собирал поддержку в ядре... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 14 июля, 2015 · Жалоба Хорошо, допустим - HTB не параллелится и стопорит RSS прерывания... Как быть? Что там во FreeBSD - стоит туда перейти. Там тоже хэши были в пайпах ipfw, задачка то, в общем, -простая - шейпер на 16 ядер / 2x10GE / 10k пайпов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
NiTr0 Опубликовано 14 июля, 2015 · Жалоба Попробовать другие дисциплины (тот же HFSC к примеру)? Какой qlen на интерфейсах к слову? Увеличивать не пробовали? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 14 июля, 2015 · Жалоба Попробовать другие дисциплины (тот же HFSC к примеру)? Какой qlen на интерфейсах к слову? Увеличивать не пробовали? Ходят слухи, что HFSC - тотже HTB. Сейчас стоит 10k txqueuelen - бестолку... Реально, напрашивается вывод, что при генерации прерывания по RSS на прерывании повисает HTB, который, видимо, имеет глобальный лок на машину. Сцук. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pavel.odintsov Опубликовано 15 июля, 2015 · Жалоба На 4м ядре тоже самое? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
voron Опубликовано 15 июля, 2015 (изменено) · Жалоба Я боюсь привет Вам передает какой-то поганый лок в ядре "74.09% [kernel] [k] _raw_spin_lock". Так ушел я от raw_spin_lock - в последних тестах он уже на уровне 5%.а не кажется ли вам, что просто занят топ idle poll'ами cpu_startup_entry и raw_spin_lock никуда не делся ? Ходят слухи, что HFSC - тотже HTB. Сейчас стоит 10k txqueuelen - бестолку... Реально, напрашивается вывод, что при генерации прерывания по RSS на прерывании повисает HTB, который, видимо, имеет глобальный лок на машину. Сцук. http://comments.gman....network/289937 не пробовали? С корневым qdisc mq и фильтрами с action skbedit queue_mapping на нем. RSS это scaling на прием, разве у вас HTB на входе интерфейса? Изменено 15 июля, 2015 пользователем voron Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 15 июля, 2015 · Жалоба Я бы попробовал вообще уйти от распределения по всем ядрам и попробовать провернуть это на одном логическом ядре. А потом с помощью, скажем, CPU опции iptables размазал трафик по всем ядрам локально, чтобы избежать блокировок вовсе. Ну и старое ядро на помойку, там столько ужаса, что никакие портеры не запортируют :) А можно осветить этот момент подробнее? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
photon Опубликовано 15 июля, 2015 (изменено) · Жалоба Не совсем понял, решает ли проблему с локами вариант с несколькими независимыми htb-деревьями поверх mq, который предложил Eric Dumazet? for ETH in eth0 do tc qdisc del dev $ETH root 2>/dev/null tc qdisc add dev $ETH root handle 100: mq for i in `seq 1 4` do tc qdisc add dev $ETH parent 100:$i handle $i htb default 1 done done Изменено 15 июля, 2015 пользователем photon Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
tartila Опубликовано 16 июля, 2015 · Жалоба Ха, спасибо огромадное за наводку на mq. :) Попробую обязательно, сейчас в отпусках, просто. Через 2 недели to be continued... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...