heap Опубликовано 17 января, 2014 · Жалоба Обнаружил интересную проблему. В сервере торчит сетевушка 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 Есть ли у кого опыт практического кручения и куда лучше крутануть? Или, возможно, где-то в другом месте... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 17 января, 2014 (изменено) · Жалоба 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, там могут быть подсказки Изменено 17 января, 2014 пользователем vitalyb Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 17 января, 2014 · Жалоба 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] Не вижу ничего военного. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 17 января, 2014 (изменено) · Жалоба vitalyb Попробую, мысль интересная. Еще можно разбить файлик на несколько частей и запускать параллельно, на всех ядрах) Изменено 17 января, 2014 пользователем kayot Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 18 января, 2014 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 января, 2014 · Жалоба heap Может есть смысл ядро поновей поставить? Символы какие-то в top'е странные попадаются, например ip_set_swap и ipt_unregister_table, не факт что остальные названия правдивые. Не знаю имеет ли отношение napi_gro_receive к включенному GRO, но проверьте еще, что выключены всякие receive offload'ы - LRO,GRO, ну и виртуализация VT-d. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 20 января, 2014 (изменено) · Жалоба 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. Изменено 20 января, 2014 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
srg555 Опубликовано 20 января, 2014 · Жалоба Как-то вред gso/tso/gro преувеличен. Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 20 января, 2014 · Жалоба 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% - это ОЧЕНЬ много. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 20 января, 2014 (изменено) · Жалоба Совсем нет, просто счастливая случайность. У вас явно что-то сильно не так с системой, столько времени по 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 - при этом прерываний не многим более чем при адекватной работе в адаптивном режиме. Буду наблюдать за поведением. Изменено 20 января, 2014 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 20 января, 2014 · Жалоба Как-то вред gso/tso/gro преувеличен. Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах В целом да - как-то пару лет назад тазик с bnx2x без выключения данных фич периодически сваливался в kernel panic. Однако в текущей ситуации я до конца не понял фокуса и эксперимент пока не завершен. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 21 января, 2014 (изменено) · Жалоба Статистика по локам покажет чем занимается 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 раза) Изменено 21 января, 2014 пользователем Painter Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 21 января, 2014 · Жалоба kayot vitalyb Про скорость работы с интерфейсами - [RFC][PATCH] iproute: Faster ip link add, set and delete Возможно в более новой версии iproute2 исправили что-то и с ip route show при наличии 100500 влан интерфейсов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 21 января, 2014 · Жалоба Painter Спасибо, интересно. Но я больше склоняюсь, что для простых и шаблонных операций следует ближе к netlink'у перебираться (генерить команды для ip/tc batch - таки суровый колхоз), для начала через библиотеку-абстракцию вроде https://pypi.python.org/pypi/pyroute2 , а дальше видно будет. Сейчас она у меня используется, чтобы следить за ARP таблицей в реальном времени, весьма удобно. В близких планах - создание/удаление маршрутов. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 21 января, 2014 · Жалоба Люди, пара дурацких вопросов. Что такое спин лок и можно ли с карты 82576 заюзать NIC LED на корпусе? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 21 января, 2014 (изменено) · Жалоба Статистика по локам покажет чем занимается 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 Изменено 21 января, 2014 пользователем heap Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 21 января, 2014 · Жалоба Люди, пара дурацких вопросов. Что такое спин лок и можно ли с карты 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 ? В общем это уже другая проблема. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 21 января, 2014 · Жалоба А в 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
kayot Опубликовано 21 января, 2014 · Жалоба Значит надо выкосить idle :) Кстати полное отключение intel_idle и установка idle_max=1(halt only) вообще не изменило реальное энергопотребление сервера(разница 2-3Вт, это уже погрешность измерений). Вообще не понимаю для чего все эти бубны придумали. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vitalyb Опубликовано 21 января, 2014 · Жалоба Вообще не понимаю для чего все эти бубны придумали. для ноутбуков, для датацентров (1 сервак - 32 8-ядерника, таких в стойке штук 5 - вот уже и не 1-2 ватта....) Но для многих околореалтаймовых задач сберегайки смерти подобны. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 21 января, 2014 (изменено) · Жалоба А что такое 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 Изменено 21 января, 2014 пользователем morfair Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 21 января, 2014 · Жалоба С дебагом локов вижу такую картинку: 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Painter Опубликовано 22 января, 2014 · Жалоба Enable collection of statistics: # echo 1 >/proc/sys/kernel/lock_stat View the top contending locks: # grep : /proc/lock_stat | head Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
morfair Опубликовано 22 января, 2014 · Жалоба Люди, как лучше агрегировать две 82576. По порту с обеих сетевух в bond, или оба порта сетевухи в бонд? Так же сколько очередей делать, если процессор четырех ядерный. По две очереди на интерфейс (с двух 82576 будет по 4 очереди на ядро), или по чертыре очереди на интерфейс (тогда с двух 82576 будет 8 очередей на ядро)? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
heap Опубликовано 22 января, 2014 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...