Jump to content
Калькуляторы

Linux softrouter

Обнаружил интересную проблему. В сервере торчит сетевушка 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

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 by vitalyb

Share this post


Link to post
Share on other sites

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

vitalyb

Попробую, мысль интересная.

Еще можно разбить файлик на несколько частей и запускать параллельно, на всех ядрах)

Edited by kayot

Share this post


Link to post
Share on other sites

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

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

Может есть смысл ядро поновей поставить? Символы какие-то в 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 by heap

Share this post


Link to post
Share on other sites

Как-то вред gso/tso/gro преувеличен.

 

Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах

Share this post


Link to post
Share on other sites

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

Совсем нет, просто счастливая случайность. У вас явно что-то сильно не так с системой, столько времени по 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 by heap

Share this post


Link to post
Share on other sites

Как-то вред gso/tso/gro преувеличен.

 

Зависит от кривизны карты и драйверы. В некоторых случаях, при их включении начинается просто ад на linux-софтроутерах

 

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

Share this post


Link to post
Share on other sites

Статистика по локам покажет чем занимается 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 by Painter

Share this post


Link to post
Share on other sites

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

Painter

Спасибо, интересно.

 

Но я больше склоняюсь, что для простых и шаблонных операций следует ближе к netlink'у перебираться (генерить команды для ip/tc batch - таки суровый колхоз), для начала через библиотеку-абстракцию вроде https://pypi.python.org/pypi/pyroute2 , а дальше видно будет. Сейчас она у меня используется, чтобы следить за ARP таблицей в реальном времени, весьма удобно. В близких планах - создание/удаление маршрутов.

Share this post


Link to post
Share on other sites

Люди, пара дурацких вопросов. Что такое спин лок и можно ли с карты 82576 заюзать NIC LED на корпусе?

Share this post


Link to post
Share on other sites

Статистика по локам покажет чем занимается 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 by heap

Share this post


Link to post
Share on other sites

Люди, пара дурацких вопросов. Что такое спин лок и можно ли с карты 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

А в 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

Значит надо выкосить idle :)

Кстати полное отключение intel_idle и установка idle_max=1(halt only) вообще не изменило реальное энергопотребление сервера(разница 2-3Вт, это уже погрешность измерений). Вообще не понимаю для чего все эти бубны придумали.

Share this post


Link to post
Share on other sites

Вообще не понимаю для чего все эти бубны придумали.

для ноутбуков, для датацентров (1 сервак - 32 8-ядерника, таких в стойке штук 5 - вот уже и не 1-2 ватта....)

 

Но для многих околореалтаймовых задач сберегайки смерти подобны.

Share this post


Link to post
Share on other sites

А что такое 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 by morfair

Share this post


Link to post
Share on other sites

С дебагом локов вижу такую картинку:

 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

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

Люди, как лучше агрегировать две 82576. По порту с обеих сетевух в bond, или оба порта сетевухи в бонд? Так же сколько очередей делать, если процессор четырех ядерный. По две очереди на интерфейс (с двух 82576 будет по 4 очереди на ядро), или по чертыре очереди на интерфейс (тогда с двух 82576 будет 8 очередей на ядро)?

Share this post


Link to post
Share on other sites

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

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now