heap Posted January 17, 2014 · Report post Обнаружил интересную проблему. В сервере торчит сетевушка 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 Есть ли у кого опыт практического кручения и куда лучше крутануть? Или, возможно, где-то в другом месте... Share this post Link to post Share on other sites
vitalyb Posted January 17, 2014 (edited) · Report post kayot Но мысль по поводу связи "времени имени интерфейса" с временем загрузки правил интересная, можно глянуть как ip/tc организовано (что передается в ядро - наверняка индекс интерфейса, который предварительно определяется из имени системным вызовом) и, особенно, есть ли там кеш. В общем полез посмотрел. Всё правда. Даже кеш есть. Но в batch режиме по факту не работает (iproute2-2.6.35), даже мешает - в обычном режиме перед запуском tc c ядра вытягивается полный список интерфейсов, а batch режим - это просто небольшая обертка над обычными командами, которые всеравно выполняются одна за другой. И каждая инициализирует кеш заново вытягиванием всех интерфейсов 8) До - real 1m9.586s user 0m9.080s sys 0m45.580s После - real 0m23.800s user 0m0.570s sys 0m0.110s Это, конечно, если я тут правильно всё намерял. Попробуйте пропатчить по аналогии diff -ur iproute2-2.6.35.orig/lib/ll_map.c iproute2-2.6.35/lib/ll_map.c --- iproute2-2.6.35.orig/lib/ll_map.c 2010-08-04 20:45:59.000000000 +0300 +++ iproute2-2.6.35/lib/ll_map.c 2014-01-17 21:26:23.000000000 +0200 @@ -185,6 +185,14 @@ int ll_init_map(struct rtnl_handle *rth) { + static int init_done = 0; + + if (init_done){ + return 0; + } + + init_done = 1; + if (rtnl_wilddump_request(rth, AF_UNSPEC, RTM_GETLINK) < 0) { perror("Cannot send dump request"); exit(1); heap Покажите более подробный вывод perf top, там могут быть подсказки Edited January 17, 2014 by vitalyb Share this post Link to post Share on other sites
heap Posted January 17, 2014 · Report post heap Покажите более подробный вывод perf top, там могут быть подсказки В момент, когда "все плохо": 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] Не вижу ничего военного. Share this post Link to post Share on other sites
kayot Posted January 17, 2014 (edited) · Report post vitalyb Попробую, мысль интересная. Еще можно разбить файлик на несколько частей и запускать параллельно, на всех ядрах) Edited January 17, 2014 by kayot Share this post Link to post Share on other sites
heap Posted January 18, 2014 · Report post heap Покажите более подробный вывод perf top, там могут быть подсказки Еще дополнительный стат. Сегодня пик проблемы пришелся на 21:00. В одном логе вывод dstat примерно за час, во втором дифф restart_queue счетчика за промежуток 1 минута. Как видно в самый пик проблемы в 21:00 счетчик: 18-01 21:00:00| 1 1 22 0 0 77| 0 0 | 622M 623M| 0 0 | 68k 5821 |named 8.6 18-01 21:00:01| 1 1 25 0 0 73| 0 110k| 606M 606M| 0 0 | 85k 8030 |named 7.4 18-01 21:00:02| 3 1 11 0 0 85|1000k 394k| 518M 507M| 0 0 | 49k 5728 |named 13 18-01 21:00:03| 4 1 0 0 0 95| 0 48k| 424M 425M| 0 0 | 16k 1600 |named 17 18-01 21:00:04| 5 2 0 0 0 93| 0 28k| 346M 348M| 0 28k| 13k 961 |named 14 18-01 21:00:05| 5 1 0 0 0 94| 0 0 | 379M 382M| 0 0 | 14k 1404 |named 14 18-01 21:00:06| 5 1 0 0 0 93| 0 366k| 407M 403M| 0 236k| 15k 1390 |named 17 18-01 21:00:07| 5 2 0 0 0 93| 0 130k| 304M 305M| 0 0 | 11k 1289 |named 18 18-01 21:00:08| 6 3 0 0 0 91|4096B 474k| 462M 466M| 0 0 | 25k 2463 |named 13 18-01 21:00:09| 4 2 0 0 0 94| 0 16k| 294M 297M| 0 0 |9843 1227 |ksoftirqd/0 5.2 18-01 21:00:10| 5 1 0 0 0 94| 0 70k| 385M 384M| 0 0 | 14k 1550 |named 13 18-01 21:00:11| 5 2 0 0 0 93| 0 12k| 390M 392M| 0 0 | 13k 1404 |named 14 18-01 21:00:12| 4 1 1 0 0 94| 0 152k| 407M 404M| 0 0 | 14k 950 |named 13 18-01 21:00:13| 5 1 0 0 0 93| 0 0 | 391M 389M| 0 0 | 12k 790 |named 16 18-01 21:00:14| 4 1 0 0 0 94| 0 0 | 340M 342M| 0 0 | 11k 659 |named 11 18-01 21:00:15| 4 1 0 0 0 95| 0 60k| 437M 436M| 0 0 | 14k 814 |named 15 18-01 21:00:16| 5 1 0 0 0 93| 0 0 | 342M 345M| 0 0 | 14k 1115 |named 15 18-01 21:00:17| 4 1 0 0 0 94| 0 200k| 389M 396M| 0 0 | 11k 918 |named 8.5 18-01 21:00:18| 4 1 0 0 0 95| 0 0 | 338M 338M| 0 0 | 10k 702 |named 12 18-01 21:00:19| 6 1 0 0 0 92| 0 0 | 448M 447M| 0 0 | 19k 1446 |named 29 18-01 21:00:20| 6 2 0 0 0 93| 0 0 | 327M 327M| 0 0 | 13k 964 |named 8.8 18-01 21:00:21| 6 3 0 0 0 91| 0 0 | 365M 366M| 0 0 | 16k 1054 |named 11 18-01 21:00:22| 4 2 0 0 0 95| 0 104k| 369M 373M| 0 0 | 11k 764 |named 20 18-01 21:00:23| 5 2 0 0 0 93| 0 4096B| 382M 378M| 0 0 | 14k 1269 |named 9.6 18-01 21:00:24| 3 1 0 0 0 96| 0 0 | 370M 371M| 0 0 | 10k 686 |named 18 18-01 21:00:25| 1 1 3 0 0 95| 0 0 | 382M 387M| 0 0 | 13k 1032 |named 13 18-01 21:00:26| 0 0 1 0 0 98| 0 0 | 333M 333M| 0 0 |4645 500 |named 14 18-01 21:00:27| 0 1 2 0 0 97| 0 58k| 381M 382M| 0 0 |7366 752 |named 14 18-01 21:00:28| 1 1 3 0 0 94| 0 106k| 378M 375M| 0 0 | 11k 1614 |named 16 18-01 21:00:29| 1 1 2 0 0 97| 0 0 | 364M 369M| 0 0 |8320 890 |named 13 18-01 21:00:30| 0 1 0 0 0 99| 0 0 | 324M 323M| 0 0 |6293 557 |named 17 18-01 21:00:31| 1 1 2 0 0 96| 0 0 | 359M 352M| 0 0 |8672 1116 |ksoftirqd/5 11 18-01 21:00:32| 1 1 2 0 0 96| 0 60k| 434M 439M| 0 0 | 11k 1162 |named 15 18-01 21:00:33| 1 1 2 0 0 96| 0 104k| 357M 358M| 0 0 |7765 1048 |named 10 18-01 21:00:34| 1 1 2 0 0 96| 0 0 | 346M 345M| 0 0 |9183 500 |named 18 18-01 21:00:35| 0 0 2 0 0 97| 0 0 | 404M 400M| 0 0 |9816 1101 |ksoftirqd/0 12 18-01 21:00:36| 1 1 4 0 0 95| 0 44k| 354M 357M| 0 0 | 11k 1296 |named 17 18-01 21:00:37| 1 1 1 0 0 98| 0 608k| 367M 371M| 0 0 |6919 955 |named 15 18-01 21:00:38| 1 1 3 0 0 95| 0 60k| 374M 377M| 0 0 | 10k 1127 |named 16 18-01 21:00:39| 0 1 1 0 0 97| 0 76k| 382M 376M| 0 0 |7726 755 |named 15 18-01 21:00:40| 1 1 2 0 0 96| 0 0 | 359M 361M| 0 0 |8708 745 |named 19 18-01 21:00:41| 1 1 2 0 0 96| 0 12k| 396M 398M| 0 0 |9118 832 |named 14 18-01 21:00:42| 1 1 1 0 0 97| 0 2048B| 352M 352M| 0 0 |5794 540 |named 9.0 18-01 21:00:43| 1 1 2 0 0 96| 0 1570k| 374M 374M| 0 0 |9546 1090 |named 16 18-01 21:00:44| 1 1 1 0 0 97| 0 28k| 396M 399M| 0 0 |9357 1002 |named 22 18-01 21:00:45| 1 1 1 0 0 97| 0 60k| 330M 320M| 0 0 |6038 759 |ksoftirqd/0 8.4 18-01 21:00:46| 1 0 1 0 0 98| 0 0 | 399M 403M| 0 0 |7696 990 |named 16 18-01 21:00:47| 0 1 2 0 0 96| 0 0 | 375M 374M| 0 0 |8267 648 |named 13 18-01 21:00:48| 0 1 1 0 0 98| 0 64k| 381M 383M| 0 0 |6528 823 |named 14 18-01 21:00:49| 1 1 3 0 0 95| 0 58k| 413M 410M| 0 0 | 13k 1875 |named 19 18-01 21:00:50| 0 0 2 0 0 98| 0 2048B| 385M 385M| 0 0 |6515 646 |named 15 18-01 21:00:51| 1 2 1 0 0 96| 0 36k| 395M 406M| 0 0 | 11k 881 |named 25 18-01 21:00:52| 1 1 1 0 0 97| 0 0 | 442M 436M| 0 0 |7395 1181 |named 21 18-01 21:00:53| 1 1 3 0 0 95| 0 28k| 313M 315M| 0 0 |8067 620 |named 14 18-01 21:00:54| 1 0 2 0 0 96| 0 0 | 438M 443M| 0 0 |9772 884 |named 21 18-01 21:00:55| 1 1 3 0 0 95| 0 36k| 347M 340M| 0 0 |8519 678 |named 9.0 18-01 21:00:56| 1 1 3 0 0 95| 0 0 | 423M 428M| 0 0 | 13k 924 |named 20 18-01 21:00:57| 1 1 2 0 0 96| 0 36k| 408M 406M| 0 0 | 10k 966 |named 14 18-01 21:00:58| 1 0 4 0 0 94| 0 48k| 428M 427M| 0 0 | 13k 1548 |named 8.8 18-01 21:00:59| 1 1 4 0 0 94| 0 0 | 409M 410M| 0 0 | 12k 1030 |named 17 18-01 21:01:00| 1 1 2 0 0 96| 0 92k| 456M 463M| 0 0 | 11k 1289 |named 17 18-01 21:01:01| 2 1 2 0 0 94| 0 0 | 396M 393M| 0 0 | 12k 2070 |named 9.0 18-01 21:01:02| 3 2 1 0 0 95| 0 60k| 413M 411M| 0 0 | 10k 763 |named 15 А счетчик: 2014-01-18_21:00:33 tx_restart_queue 6041 2014-01-18_21:01:33 tx_restart_queue 12942 2014-01-18_21:02:34 tx_restart_queue 12157 2014-01-18_21:03:34 tx_restart_queue 12488 2014-01-18_21:04:36 tx_restart_queue 14314 2014-01-18_21:05:36 tx_restart_queue 14700 2014-01-18_21:06:37 tx_restart_queue 14721 2014-01-18_21:07:38 tx_restart_queue 15298 2014-01-18_21:08:38 tx_restart_queue 11367 2014-01-18_21:09:39 tx_restart_queue 8455 2014-01-18_21:10:39 tx_restart_queue 9395 2014-01-18_21:11:40 tx_restart_queue 9244 2014-01-18_21:12:40 tx_restart_queue 5025 2014-01-18_21:13:40 tx_restart_queue 2482 Когда проблема не дает о себе ощутимо знать - dstat выглядит так: 18-01 22:00:06| 1 1 37 0 0 62| 0 0 | 591M 590M| 0 0 | 112k 12k|named 4.2 18-01 22:00:07| 1 0 38 0 0 61| 0 108k| 578M 578M| 0 0 | 114k 12k|named 4.0 18-01 22:00:08| 1 0 36 0 0 63| 0 0 | 571M 571M| 0 0 | 107k 11k|named 3.9 18-01 22:00:09| 1 1 37 0 0 62| 0 36k| 559M 560M| 0 0 | 111k 12k|named 4.0 18-01 22:00:10| 1 0 38 0 0 60| 0 66k| 574M 574M| 0 0 | 109k 11k|named 4.1 18-01 22:00:11| 1 1 34 0 0 65| 0 2048B| 585M 586M| 0 0 | 111k 11k|named 3.9 18-01 22:00:12| 1 1 35 0 0 64| 0 0 | 594M 595M| 0 0 | 107k 11k|named 4.6 18-01 22:00:13| 1 1 33 0 0 66| 0 0 | 601M 601M| 0 0 | 106k 11k|named 4.5 18-01 22:00:14| 1 1 32 0 0 66| 0 0 | 604M 604M| 0 0 | 104k 11k|named 5.1 18-01 22:00:15| 1 1 32 0 0 66| 0 36k| 590M 590M| 0 0 | 101k 11k|named 6.8 trouble_dstat.txt trouble_restart_queue.txt Share this post Link to post Share on other sites
vitalyb Posted January 20, 2014 · Report post heap Может есть смысл ядро поновей поставить? Символы какие-то в top'е странные попадаются, например ip_set_swap и ipt_unregister_table, не факт что остальные названия правдивые. Не знаю имеет ли отношение napi_gro_receive к включенному GRO, но проверьте еще, что выключены всякие receive offload'ы - LRO,GRO, ну и виртуализация VT-d. Share this post Link to post Share on other sites
heap Posted January 20, 2014 (edited) · Report post heap Может есть смысл ядро поновей поставить? Символы какие-то в top'е странные попадаются, например ip_set_swap и ipt_unregister_table, не факт что остальные названия правдивые. Не знаю имеет ли отношение napi_gro_receive к включенному GRO, но проверьте еще, что выключены всякие receive offload'ы - LRO,GRO, ну и виртуализация VT-d. На самом деле на этом тазу не выключал ничего насильно - выглядит текущая картинка как: # 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. Edited January 20, 2014 by heap Share this post Link to post Share on other sites
srg555 Posted January 20, 2014 · Report post Как-то вред gso/tso/gro преувеличен. Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах Share this post Link to post Share on other sites
vitalyb Posted January 20, 2014 · Report post PS: Что примечательно - выключил gro/gso/tso - увеличился pps трафика в сторону абонентов - эдак со 170 до 220кппс и ощутимо увеличилась загрузка CPU. При этом потребление в мегабитах осталось примерно прежним. Где секрет фокуса? Значит оно таки включено и работает, надо выключать. PPS: Как-то вред gso/tso/gro преувеличен. После их отключения сразу появились restart_queue, которых кроме как в ЧНН обычно не было. При трафике суммарно по серверу 2.87/2.87 процессор откушался почти полностью, в то время как с ними в ЧНН с небольшим запасом трафик достигал 5.27/5.27. Совсем нет, просто счастливая случайность. У вас явно что-то сильно не так с системой, столько времени по perf top в спинлоке - однозначно неправильно. *RO/*SO действительно призвано снижать pps и это позволяет спасти ситуацию в критические моменты. "Нормальный" маршрутизатор должен принять пакет, решить куда его отправить и отправить. Со включенным GRO он принимает первый пакет, второй, десятый, потом видит что одиннадцатый - продолжение первого, дописывает его в конец первого, 12й- новый, .. 25 - продолжение второго, итд. Но ресурсы не безграничны, адаптер не может следить за миллионом потоков - очереди забиваются, начинаются дропы и прочий ад. Это предназначено для файловых и веб серверов (и тоже не для обслуживания миллиона клиентов). Ищите кто это у вас вылазит в спинлоке (если это, конечно действительно спинлок), хоть выключением подсистем (фаервол, шейпер итд), хоть как, 40% - это ОЧЕНЬ много. Share this post Link to post Share on other sites
heap Posted January 20, 2014 (edited) · Report post Совсем нет, просто счастливая случайность. У вас явно что-то сильно не так с системой, столько времени по perf top в спинлоке - однозначно неправильно. *RO/*SO действительно призвано снижать pps и это позволяет спасти ситуацию в критические моменты. Ищите кто это у вас вылазит в спинлоке (если это, конечно действительно спинлок), хоть выключением подсистем (фаервол, шейпер итд), хоть как, 40% - это ОЧЕНЬ много. Тут есть два нюанса. Спин лок в топе у меня не только на этом 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 - при этом прерываний не многим более чем при адекватной работе в адаптивном режиме. Буду наблюдать за поведением. Edited January 20, 2014 by heap Share this post Link to post Share on other sites
heap Posted January 20, 2014 · Report post Как-то вред gso/tso/gro преувеличен. Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах В целом да - как-то пару лет назад тазик с bnx2x без выключения данных фич периодически сваливался в kernel panic. Однако в текущей ситуации я до конца не понял фокуса и эксперимент пока не завершен. Share this post Link to post Share on other sites
Painter Posted January 21, 2014 (edited) · Report post Статистика по локам покажет чем занимается spin_lock. Я вам отвечал на этот вопрос в теме про HTB шейпер TC HTB упирается в 2Гбит/c (хотя там был raw_spin_lock, а не __ticket_spin_lock) P.S. про второй bras 11,93% [kernel] [k] read_hpet TSС работает заметно быстрее. Попробуйте заменить. (у меня включение hpet увеличивало загрузку CPU на шейпере в 2 раза) Edited January 21, 2014 by Painter Share this post Link to post Share on other sites
Painter Posted January 21, 2014 · Report post kayot vitalyb Про скорость работы с интерфейсами - [RFC][PATCH] iproute: Faster ip link add, set and delete Возможно в более новой версии iproute2 исправили что-то и с ip route show при наличии 100500 влан интерфейсов. Share this post Link to post Share on other sites
vitalyb Posted January 21, 2014 · Report post Painter Спасибо, интересно. Но я больше склоняюсь, что для простых и шаблонных операций следует ближе к netlink'у перебираться (генерить команды для ip/tc batch - таки суровый колхоз), для начала через библиотеку-абстракцию вроде https://pypi.python.org/pypi/pyroute2 , а дальше видно будет. Сейчас она у меня используется, чтобы следить за ARP таблицей в реальном времени, весьма удобно. В близких планах - создание/удаление маршрутов. Share this post Link to post Share on other sites
morfair Posted January 21, 2014 · Report post Люди, пара дурацких вопросов. Что такое спин лок и можно ли с карты 82576 заюзать NIC LED на корпусе? Share this post Link to post Share on other sites
heap Posted January 21, 2014 (edited) · Report post Статистика по локам покажет чем занимается spin_lock. Я вам отвечал на этот вопрос в теме про HTB шейпер TC HTB упирается в 2Гбит/c (хотя там был raw_spin_lock, а не __ticket_spin_lock) P.S. про второй bras 11,93% [kernel] [k] read_hpet TSС работает заметно быстрее. Попробуйте заменить. (у меня включение hpet увеличивало загрузку CPU на шейпере в 2 раза) Спасибо, видимо вылетело из головы. Обязательно потестирую. А что касается tsc - к сожалению, именно там у меня выбор невелик: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm Edited January 21, 2014 by heap Share this post Link to post Share on other sites
Painter Posted January 21, 2014 · Report post Люди, пара дурацких вопросов. Что такое спин лок и можно ли с карты 82576 заюзать NIC LED на корпусе? Это один из механизмов синхронизации доступа нескольких потоков к какой-то структуре данных. Спинлок ограничивает доступ к этим данным, пока с ними работает другой поток. А "spin", потому что ожидающий освобождения блокировки поток, "крутится" в бесконечном цикле. Spinlock Spinlock. Linux Documentation 82576eb-gigabit-ethernet-controller-datashee - стр. 50, секция 1.4.9 - LEDs Interface. Может можно как-то этим управлять. Спасибо, видимо вылетело из головы. Обязательно потестирую. А что касается tsc - к сожалению, именно там у меня выбор невелик: # cat /sys/devices/system/clocksource/clocksource0/available_clocksource hpet acpi_pm А в dmesg было сообщение типа?: Sep 17 22:34:19 hostname kernel: [1343117.109123] Clocksource tsc unstable (delta = 299966045123 ns) Sep 17 22:34:19 hostname kernel: [1343117.114812] Switching to clocksource hpet Потому что TSC счетчик он встроен в процессор, не знаю, почему он может быть не доступен. CONFIG_X86_TSC=y ? В общем это уже другая проблема. Share this post Link to post Share on other sites
heap Posted January 21, 2014 · Report post А в dmesg было сообщение типа?: Sep 17 22:34:19 hostname kernel: [1343117.109123] Clocksource tsc unstable (delta = 299966045123 ns) Sep 17 22:34:19 hostname kernel: [1343117.114812] Switching to clocksource hpet Потому что TSC счетчик он встроен в процессор, не знаю, почему он может быть не доступен. CONFIG_X86_TSC=y ? В общем это уже другая проблема. CONFIG_X86_TSC=y А в dmesg: [ 0.000000] Fast TSC calibration using PIT [ 0.710338] Marking TSC unstable due to TSC halts in idle Share this post Link to post Share on other sites
kayot Posted January 21, 2014 · Report post Значит надо выкосить idle :) Кстати полное отключение intel_idle и установка idle_max=1(halt only) вообще не изменило реальное энергопотребление сервера(разница 2-3Вт, это уже погрешность измерений). Вообще не понимаю для чего все эти бубны придумали. Share this post Link to post Share on other sites
vitalyb Posted January 21, 2014 · Report post Вообще не понимаю для чего все эти бубны придумали. для ноутбуков, для датацентров (1 сервак - 32 8-ядерника, таких в стойке штук 5 - вот уже и не 1-2 ватта....) Но для многих околореалтаймовых задач сберегайки смерти подобны. Share this post Link to post Share on other sites
morfair Posted January 21, 2014 (edited) · Report post А что такое mutex_spin_on_owner? (debian 7 64, 802.3ad layer2+3 (2), accel-ppp) 16,18% [ecb] [k] crypto_ecb_crypt 10,13% [kernel] [k] mutex_spin_on_owner 9,10% [arc4] [k] arc4_set_key 7,82% [arc4] [k] arc4_crypt Edited January 21, 2014 by morfair Share this post Link to post Share on other sites
heap Posted January 21, 2014 · Report post С дебагом локов вижу такую картинку: 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 Share this post Link to post Share on other sites
Painter Posted January 22, 2014 · Report post Enable collection of statistics: # echo 1 >/proc/sys/kernel/lock_stat View the top contending locks: # grep : /proc/lock_stat | head Share this post Link to post Share on other sites
morfair Posted January 22, 2014 · Report post Люди, как лучше агрегировать две 82576. По порту с обеих сетевух в bond, или оба порта сетевухи в бонд? Так же сколько очередей делать, если процессор четырех ядерный. По две очереди на интерфейс (с двух 82576 будет по 4 очереди на ядро), или по чертыре очереди на интерфейс (тогда с двух 82576 будет 8 очередей на ядро)? Share this post Link to post Share on other sites
heap Posted January 22, 2014 · Report post Enable collection of statistics: # echo 1 >/proc/sys/kernel/lock_stat View the top contending locks: # grep : /proc/lock_stat | head # 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 Share this post Link to post Share on other sites
