heap

Кому-то удалось найти эффективный способ вычисления виновников?

Я снимал стат не на сервере, где ixgbe, а с другого для анализа почему лок в принципе в топе везде. Там где ixgbe он уходил в гораздо более ощутимый отрыв, когда возникала проблема. Однако провести там анализ будет затруднительно, так как там где я тестировал с этими опциями нагрузка на CPU увеличивалась в разы, а значит я даже не смогу прожевать там тот объем трафика, с которого начиналась проблема. Пока наблюдаю за поведением с rx-usecs выставленным в значение, а не адаптивным. Также все же меня интересует вопрос с gro. Полопатив вчера гуголь и почитав на его тему - я не вижу от него ощутимого вреда для роутера (ну разве что для малых значений скоростей в шейпере). TSO/GSO судя по всему действительно лишнее. А вот с GRO ощутимо уменьшается нагрузка на CPU роутера в то время, как PPS и полоса остаются те же. По крайней мере в моем случае, так как по одну сторону от роутера бордер - 1 мак, по другую несколько агрегаторов - несколько маков. В итоге судя по описанию он на уровне сетевой собирает пакеты и пачкой передает на обработку в ядро, что, по видимому, сказывается в том числе на количестве прерываний и нагрузке. На джиттере также ничего военного не заметил.

# grep : /proc/lock_stat | head &qdisc_tx_lock: 7879676 7891450 0.02 58.97 18897832.51 2.39 18313196 25463372 0.00 1381.51 74968629.51 2.94 &qdisc_rx_lock: 4269891 4270657 0.03 112.61 22798303.60 5.34 10176748 11014051 0.00 59.23 66942204.74 6.08 hlist_lock: 4002876 4012490 0.01 43.03 3575001.05 0.89 25195249 30822163 0.00 59.01 24209650.84 0.79 dev->qdisc_tx_busylock ?: &qdisc_tx#2: 2096762 2097048 0.17 94.38 8257583.16 3.94 7399628 8218268 0.00 49.40 37961652.14 4.62 dev->qdisc_tx_busylock ?: &qdisc_tx#2 2097061 [<ffffffff8160e609>] __dev_queue_xmit+0x669/0x6c0 dev->qdisc_tx_busylock ?: &qdisc_tx#2 2097061 [<ffffffff8160e609>] __dev_queue_xmit+0x669/0x6c0 &(&list->lock)->rlock#2: 276883 278244 0.18 17.26 202258.18 0.73 18692831 32309112 0.00 31.47 14901988.23 0.46 &(*(&acpi_gbl_hardware_lock))->rlock: 89739 89739 0.49 29.51 191179.97 2.13 284676 298433 0.00 19.33 487026.66 1.63 clockevents_lock: 78570 78574 0.18 15.56 148040.91 1.88 572334 684371 0.00 18.08 243657.37 0.36 &(&list->lock)->rlock#3: 71867 72105 0.20 26.96 51095.76 0.71 13532911 48009852 0.00 36.58 14513650.07 0.30

С дебагом локов вижу такую картинку: 8,92% swapper [kernel.kallsyms] [k] __lock_acquire.isra.30 2,86% swapper [kernel.kallsyms] [k] sched_clock_local 2,62% swapper [kernel.kallsyms] [k] native_sched_clock 2,40% swapper [kernel.kallsyms] [k] lock_release 2,08% swapper [kernel.kallsyms] [k] delay_tsc 2,07% swapper [kernel.kallsyms] [k] check_chain_key 1,92% swapper [kernel.kallsyms] [k] read_hpet 1,90% swapper [kernel.kallsyms] [k] local_clock 1,87% swapper [kernel.kallsyms] [k] lock_acquire 1,52% ksoftirqd/6 [kernel.kallsyms] [k] __lock_acquire.isra.30 1,37% ksoftirqd/4 [kernel.kallsyms] [k] __lock_acquire.isra.30 1,36% swapper [kernel.kallsyms] [k] sched_clock_cpu 1,20% swapper [kernel.kallsyms] [k] lock_release_holdtime.part.20 1,16% ksoftirqd/2 [kernel.kallsyms] [k] __lock_acquire.isra.30 1,06% swapper [kernel.kallsyms] [k] do_raw_spin_trylock 0,95% kworker/3:1 [kernel.kallsyms] [k] __lock_acquire.isra.30 0,94% kworker/3:0 [kernel.kallsyms] [k] __lock_acquire.isra.30 0,83% swapper [ip_set_hash_net] [k] hash_net4_test 0,81% swapper [ip_set] [k] ip_set_test 0,81% swapper [kernel.kallsyms] [k] lock_acquired 0,79% swapper [cls_u32] [k] u32_classify 0,74% swapper [kernel.kallsyms] [k] fib_table_lookup 0,73% swapper [ip_tables] [k] ipt_do_table 0,69% swapper [kernel.kallsyms] [k] do_raw_read_trylock 0,66% ksoftirqd/5 [kernel.kallsyms] [k] __lock_acquire.isra.30 0,66% swapper [igb] [k] igb_poll 0,61% ksoftirqd/0 [kernel.kallsyms] [k] __lock_acquire.isra.30 0,49% ksoftirqd/6 [kernel.kallsyms] [k] sched_clock_local 0,48% swapper [kernel.kallsyms] [k] __slab_free 0,48% swapper [ipt_NETFLOW] [k] 0x0000000000003d30 0,47% swapper [kernel.kallsyms] [k] __netif_receive_skb_core 0,44% ksoftirqd/6 [kernel.kallsyms] [k] delay_tsc 0,44% ksoftirqd/6 [kernel.kallsyms] [k] native_sched_clock 0,43% swapper [kernel.kallsyms] [k] do_raw_spin_lock 0,42% swapper [kernel.kallsyms] [k] __dev_queue_xmit 0,42% ksoftirqd/4 [kernel.kallsyms] [k] sched_clock_local

CONFIG_X86_TSC=y А в dmesg: [ 0.000000] Fast TSC calibration using PIT [ 0.710338] Marking TSC unstable due to TSC halts in idle

TSС работает заметно быстрее. Попробуйте заменить. (у меня включение hpet увеличивало загрузку CPU на шейпере в 2 раза) Спасибо, видимо вылетело из головы. Обязательно потестирую. А что касается tsc - к сожалению, именно там у меня выбор невелик: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm

Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах В целом да - как-то пару лет назад тазик с bnx2x без выключения данных фич периодически сваливался в kernel panic. Однако в текущей ситуации я до конца не понял фокуса и эксперимент пока не завершен.

Тут есть два нюанса. Спин лок в топе у меня не только на этом bras. Вот, пример, с другого: 18,56% [kernel] [k] __ticket_spin_lock 11,93% [kernel] [k] read_hpet 2,90% [igb] [k] igb_poll Там другой процессор, другие сетевые, другая версия ядра - но спин лок все равно в топе. Единственный нюанс - он в топе с 17-20% как правило. В случае же рассматриваемой проблемы - в некий момент знатно уменьшается количество прерываний, начинается рост счетчика tx_restart_queue, а в это время увеличивается скачкообразно нагрузка на CPU. Причем в случае gro/gso/tso оно едет до указанной величины в два раза большей, нежели при их отключении. И что примечательно - вплоть до той величины (5.х/5.х) сквозь роутер я тяну нормальную скорость (в мегабитах - в ппс не пробовал). Если кратко подвести итог, то выходит: 1. Выключение gso/gro/tso даже не в ЧНН приводит к росту tx_restart_queue, использования CPU и по сути уменьшает ресурс роутера в разы. 2. С включенным gso/gro/tso при достижении определенного лимита трафика все равно появляется тот самый tx_restart_queue, после чего в топ врывается ticket spin lock, а остаток ресурса CPU сжирается совсем в иной пропорции, нежели до этого. Примечательно, что в данный момент катастрофически проваливается количество прерываний. Причем, когда по дефолту стояли размеры ring buffer - рост tx_restart_queue начинался при нагрузке около 2.5/2.5 по трафику и из-за этого упирался в эту величину. После установки ring buffer rx/tx 4096/4096 проблема исчезла до текущих величин трафика. И вот вопрос - есть ли ей лечение в виде, например, ковыряния coalescing, или же проблема не разрешима? Из дополнительных функций, которые выполняет таз: ipt_NETFLOW, htb+u32 hashing filters, SNAT. PS: Откопал док (http://www.intel.com/content/dam/doc/application-note/82575-82576-82598-82599-ethernet-controllers-latency-appl-note.pdf) - установленное по дефолту rx-usecs 1 - это adaptive режим, который судя по всему в какой-то момент адаптируется на слишком низкое количество. Попробовал убрать модерацию совсем - раза в три становится больше прерываний и увеличивается загрузка CPU. Подобрал значение 100 - при этом прерываний не многим более чем при адекватной работе в адаптивном режиме. Буду наблюдать за поведением.

На самом деле на этом тазу не выключал ничего насильно - выглядит текущая картинка как: # ethtool -k eth6 Offload parameters for eth6: rx-checksumming: on tx-checksumming: on scatter-gather: on tcp-segmentation-offload: 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 То бишь gro/gso/tso вроде бы как включено. Однако, ЕМНИП, их вредоносное влияние касается шейпера - в его работе косяков не замечено. Могут ли они вносить свое влияние на интерапты и количество restart queue? Попробовал tx-frames-irq поднять с 256 до 512 и rx-usecs выставить вместо 1 - 10. По описанию в интернете - это должно увеличить количество как rx, так и tx прерываний. И фактически действительно - нагрузки прошло поболее и tx_restart_queue уже капал куда меньшими (хотя и не малыми) величинами и уже на полосе не так сказывался, хотя все равно был и увеличивал загрузку CPU. Обновить ядро, конечно, можно - но пока хочется разобраться с самой сутью провала количества прерываний и сильного роста tx_restart_queue. PS: Что примечательно - выключил gro/gso/tso - увеличился pps трафика в сторону абонентов - эдак со 170 до 220кппс и ощутимо увеличилась загрузка CPU. При этом потребление в мегабитах осталось примерно прежним. Где секрет фокуса? PPS: Как-то вред gso/tso/gro преувеличен. После их отключения сразу появились restart_queue, которых кроме как в ЧНН обычно не было. При трафике суммарно по серверу 2.87/2.87 процессор откушался почти полностью, в то время как с ними в ЧНН с небольшим запасом трафик достигал 5.27/5.27.

Еще дополнительный стат. Сегодня пик проблемы пришелся на 21:00. В одном логе вывод dstat примерно за час, во втором дифф restart_queue счетчика за промежуток 1 минута. Как видно в самый пик проблемы в 21:00 счетчик: А счетчик: Когда проблема не дает о себе ощутимо знать - dstat выглядит так: trouble_dstat.txt trouble_restart_queue.txt

В момент, когда "все плохо": PerfTop: 5913 irqs/sec kernel:99.5% exact: 0.0% [1000Hz cycles], (all, 8 CPUs) ----------------------------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ _____________________________________________ __________________________________________________________________________ 18360.00 43.5% __ticket_spin_lock [kernel.kallsyms] 2366.00 5.6% u32_dump /lib/modules/3.0.0-13-server/kernel/net/sched/cls_u32.ko 1895.00 4.5% ipt_unregister_table /lib/modules/3.0.0-13-server/kernel/net/ipv4/netfilter/ip_tables.ko 1227.00 2.9% ip_route_input_common [kernel.kallsyms] 1120.00 2.7% hash_net4_test_cidrs.isra.6 /lib/modules/3.0.0-13-server/kernel/net/netfilter/ipset/ip_set_hash_net.ko 1059.00 2.5% _raw_read_lock_bh [kernel.kallsyms] 709.00 1.7% ixgbe_unmap_and_free_tx_resource /lib/modules/3.0.0-13-server/kernel/drivers/net/ixgbe/ixgbe.ko 618.00 1.5% rate_timer_calc [ipt_NETFLOW] 596.00 1.4% ip_set_swap /lib/modules/3.0.0-13-server/kernel/net/netfilter/ipset/ip_set.ko 594.00 1.4% nf_iterate [kernel.kallsyms] 578.00 1.4% ixgbe_xmit_frame_ring /lib/modules/3.0.0-13-server/kernel/drivers/net/ixgbe/ixgbe.ko 528.00 1.3% tc_classify_compat [kernel.kallsyms] 466.00 1.1% htb_dequeue /lib/modules/3.0.0-13-server/kernel/net/sched/sch_htb.ko 398.00 0.9% _raw_read_unlock_bh [kernel.kallsyms] 388.00 0.9% local_bh_enable [kernel.kallsyms] 374.00 0.9% htb_init /lib/modules/3.0.0-13-server/kernel/net/sched/sch_htb.ko 341.00 0.8% dev_queue_xmit [kernel.kallsyms] 340.00 0.8% napi_gro_receive [kernel.kallsyms] 316.00 0.7% kmem_cache_alloc_node [kernel.kallsyms] 297.00 0.7% __kmalloc_node_track_caller [kernel.kallsyms] 277.00 0.7% memcmp [kernel.kallsyms] 210.00 0.5% local_bh_disable [kernel.kallsyms] 205.00 0.5% __netif_receive_skb [kernel.kallsyms] 201.00 0.5% dst_release [kernel.kallsyms] 196.00 0.5% hash_ip4_kadt /lib/modules/3.0.0-13-server/kernel/net/netfilter/ipset/ip_set_hash_ip.ko 195.00 0.5% nf_nat_rule_cleanup /lib/modules/3.0.0-13-server/kernel/net/ipv4/netfilter/iptable_nat.ko 191.00 0.5% __memcpy [kernel.kallsyms] 191.00 0.5% local_bh_enable_ip [kernel.kallsyms] 187.00 0.4% skb_release_head_state [kernel.kallsyms] В момент, когда нормально: PerfTop: 1017 irqs/sec kernel:95.9% exact: 0.0% [1000Hz cycles], (all, 8 CPUs) ----------------------------------------------------------------------------------------------------------------------------------------------------------- samples pcnt function DSO _______ _____ _____________________________________________ __________________________________________________________________________ 262.00 13.3% __ticket_spin_lock [kernel.kallsyms] 149.00 7.6% ipt_unregister_table /lib/modules/3.0.0-13-server/kernel/net/ipv4/netfilter/ip_tables.ko 92.00 4.7% u32_dump /lib/modules/3.0.0-13-server/kernel/net/sched/cls_u32.ko 88.00 4.5% hash_net4_test_cidrs.isra.6 /lib/modules/3.0.0-13-server/kernel/net/netfilter/ipset/ip_set_hash_net.ko 74.00 3.8% ip_route_input_common [kernel.kallsyms] 54.00 2.7% ixgbe_unmap_and_free_tx_resource /lib/modules/3.0.0-13-server/kernel/drivers/net/ixgbe/ixgbe.ko 47.00 2.4% nf_iterate [kernel.kallsyms] 45.00 2.3% rate_timer_calc [ipt_NETFLOW] 45.00 2.3% _raw_read_lock_bh [kernel.kallsyms] 44.00 2.2% acpi_idle_do_entry [kernel.kallsyms] 42.00 2.1% ixgbe_xmit_frame_ring /lib/modules/3.0.0-13-server/kernel/drivers/net/ixgbe/ixgbe.ko 36.00 1.8% ip_set_swap /lib/modules/3.0.0-13-server/kernel/net/netfilter/ipset/ip_set.ko 35.00 1.8% _raw_read_unlock_bh [kernel.kallsyms] 31.00 1.6% tc_classify_compat [kernel.kallsyms] 23.00 1.2% htb_dequeue /lib/modules/3.0.0-13-server/kernel/net/sched/sch_htb.ko 19.00 1.0% dev_queue_xmit [kernel.kallsyms] 16.00 0.8% __netif_receive_skb [kernel.kallsyms] 15.00 0.8% kmem_cache_free [kernel.kallsyms] 15.00 0.8% __nf_conntrack_confirm /lib/modules/3.0.0-13-server/kernel/net/netfilter/nf_conntrack.ko 14.00 0.7% local_bh_disable [kernel.kallsyms] 14.00 0.7% __kmalloc_node_track_caller [kernel.kallsyms] 14.00 0.7% htb_enqueue /lib/modules/3.0.0-13-server/kernel/net/sched/sch_htb.ko 14.00 0.7% htb_init /lib/modules/3.0.0-13-server/kernel/net/sched/sch_htb.ko 14.00 0.7% bit_spin_lock.constprop.58 [kernel.kallsyms] 13.00 0.7% kmem_cache_alloc_node [kernel.kallsyms] 13.00 0.7% memcmp [kernel.kallsyms] 13.00 0.7% __memcpy [kernel.kallsyms] 12.00 0.6% skb_release_head_state [kernel.kallsyms] 12.00 0.6% native_read_tsc [kernel.kallsyms] Не вижу ничего военного.

Обнаружил интересную проблему. В сервере торчит сетевушка 82599EB (10G). Включена по 10Г, внешний интерфейс без тага, внутренний с тагом. Получается по одному физическому интерфейсу трафик приходит и по нему же уходит. Наблюдается следующее. Едет все нормально до определенного момента, когда трафик по входу и исходу достигает отметки порядка 5Г вошло и 5Г вышло. После чего загрузка CPU скачкообразно приближается к 100%, скорость падает, и трафика уходит меньше, чем входит. Что видим. По интерфейсу начинает ощутимо расти счетчик tx_restart_queue. Также пока все нормально незадолго до проблем количество прерываний: # mpstat -I SUM 1 21:14:20 CPU intr/s 21:14:21 all 80264,00 21:14:22 all 89598,00 21:14:23 all 96584,00 21:14:24 all 70900,00 21:14:25 all 70535,00 21:14:26 all 86003,00 Во время проблемы: # mpstat -I SUM 1 21:02:09 CPU intr/s 21:02:10 all 17975,00 21:02:11 all 13501,00 21:02:12 all 12579,00 21:02:13 all 16571,29 21:02:14 all 16148,00 В perf top на первом месте с отрывом от "рабочего режима" процентов на 20: 18360.00 43.5% __ticket_spin_lock [kernel.kallsyms] При этом: # ethtool -g eth6 Ring parameters for eth6: Pre-set maximums: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Current hardware settings: RX: 4096 RX Mini: 0 RX Jumbo: 0 TX: 4096 Внешне очень похоже на InterruptThrottleRate. Настройки стоят такие (по умолчанию): # ethtool -c eth6 Coalesce parameters for eth6: 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 Судя по всему покрутить нужно что-то в этой области: tx-usecs: 0 tx-frames: 0 tx-usecs-irq: 0 tx-frames-irq: 256 Есть ли у кого опыт практического кручения и куда лучше крутануть? Или, возможно, где-то в другом месте...

ethtool -C?

ИМХО, по идее работоспособный вариант. У самого есть нечто подобное, правда на 4-х ядрах. По личному наблюдению, плохо когда одна очередь/прерывание болтается на разных ядрах. Где-то тут на форуме обсуждали и про вымывание кешей, и про другие тонкости.

lsmod среди прочего кажет: iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables x_tables nf_conntrack_ipv4 nf_defrag_ipv4 nf_conntrack То бишь как вроде бы ничего лишнего. Из netfilter есть: xt_CT xt_mark xt_state xt_tcpudp xt_hashlimit xt_set Можно ли поподробнее в двух словах об sg. Какой выигрыш в производительности он дает включенный на роутере? Касательно bnx - драйвер ядерный ездит. Почему-то с оффсайта со свежими ядрами не компилится. Ага, на сервачке с e1000e где-то встречалось такое. Не помню приводило ли к дизастеру, но такие сообщения встречались. Про bnx2 соврал. Уже есть, которые собираются.