1

在将 linux 从内核 3.4 升级到 4.1 版本时，我们发现了性能下降问题。看来，这是因为新内核花费了更多时间来服务软中断。

我们使用生成 GTP-C 数据包（通过 UDP）的流量生成器 (IXIA) 和一个简单的应用程序进行了测试，该应用程序将接收到的数据包发回。它只是交换源 IP 地址和目标 IP 地址。我们使用 mpstat 实用程序得到以下结果：

  • 内核 3.4
# mpstat -P 全部 60 1
Linux 3.4.91-grsec (...) 12/22/17 _x86_64_ (20 CPU)

15:58:43 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
15:58:53 全部 0.26 0.00 2.21 0.00 0.00 0.41 0.00 0.00 97.12
15:58:53 0 1.03 0.00 3.79 0.00 0.00 12.91 0.00 0.00 82.27
15:58:53 1 4.18 0.00 41.44 0.00 0.00 0.00 0.00 0.00 54.38
15:58:53 2 0.30 0.00 0.30 0.00 0.00 0.40 0.00 0.00 99.00
...

# mpstat -I ALL -P 0 60 1
Linux 3.4.91-grsec (...) 12/25/17 _x86_64_ (20 CPU)

10:53:16 CPU intr/s
10:54:16 0 0.00

10:53：16 CPU 0/s 3/s 4/s 8/s 9/s 67/s 68/s 69/s 70/s 71/s 72/s 73/s 74/s 75/s 76/s 77/s 78/秒 79/秒 80/秒 81/秒 82/秒 83/秒 84/秒 103/秒 104/秒 105/秒 106/秒 107/秒 108/秒 109/秒 110/秒 111/秒 112/秒 113/秒 114/秒 115/秒 116/秒 117/秒 118/秒 119/秒 120/秒 121/秒 122/秒 123/秒 124/秒 125/秒 126/秒 127/秒 128/秒 129 /s 130/s 131/s 132/s 133/s 134/s 135/s 136/s 137/s 138/s 139/s 140/s 141/s 142/s 143/s 144/s NMI/s LOC/s SPU/s PMI/s IWI/s RTR/s RES/s CAL/s TLB/s TRM/s THR/s MCE/sMCP/s ERR/s MIS/s
10:54:16 0 0.00 5.50 0.00 0.00 0.00 0.00 71.59 0.50 1.60 6.47 1.50 16.66 0.50 1.50 0.00 71.59 0.50 0.60 6.47 1.50 16.66 1.50 1.50 126.91 17445.01 9.93 1.87 1.28 1.25 1.27 4.82 0.83 1.37 1.58 7.45 14.38 3.45 18060.49 2.18 0.97 1.00 0.58 0.83 0.00 87.70 17503.72 7.62 1.22 0.75 0.67 0.98 2.98 0.53 1.53 1.58 1.58 1.50 6.62 18028.71 1.53 0.53 0.53 0.50 0.50 0.50 0.50 0.50 0.50 0.40 0.40 0.40 0.40 174.64 0.00 0.00 0.00 0.40 0.40 0.40 0.00 0.00 0.00 0.00 282.00 0.00 0.00 0.92 0.00 0.00 0.00 0.00 0。00 0.00 0.00 0.00 0.00

10:53:16 CPU HI/s TIMER/s NET_TX/s NET_RX/s BLOCK/s BLOCK_IOPOLL/s TASKLET/s SCHED/s HRTIMER/s RCU/s
10:54:16 0 0.00 166.49 0.25 62813.75 0.00 0.00 0.00 298.20 0.87 130.00
...
  • 内核 4.1
# mpstat -P 全部 60 1
Linux 4.1.21 (...) 12/22/17 _x86_64_ (20 CPU)

16:19:12 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle
16:19:22 全部 0.28 0.00 2.23 0.00 0.00 2.65 0.00 0.00 94.84
16:19:22 0 1.40 0.00 2.59 0.00 0.00 52.79 0.00 0.00 43.21
16:19:22 1 3.66 0.00 42.47 0.00 0.00 0.00 0.00 0.00 53.87
16:19:22 2 0.10 0.00 0.20 0.00 0.00 0.00 0.00 0.00 99.70
...

# mpstat -I ALL -P 0 60 1
Linux 4.1.21 (...) 12/25/17 _x86_64_ (20 CPU)

10:35:45 CPU intr/s
10:36:45 0 0.00

10:35：45 CPU 0/s 3/s 4/s 8/s 9/s 31/s 32/s 33/s 34/s 35/s 36/s 37/s 38/s 39/s 41/s 42/s 43/s 44/s 45/s 46/s 47/s 48/s 49/s 69/s 70/s 71/s 72/s 73/s 74/s 75/s 76/s 77/s 78/秒 79/秒 80/秒 81/秒 82/秒 83/秒 84/秒 85/秒 86/秒 87/秒 88/秒 89/秒 91/秒 92/秒 93/秒 94/秒 95/秒 96 /s 97/s 98/s 99/s 100/s 101/s 102/s 103/s 104/s 105/s 106/s 107/s 108/s 109/s 110/s 111/s NMI/s LOC/s SPU/s PMI/s IWI/s RTR/s RES/s CAL/s TLB/s TRM/s THR/s MCE/sMCP/s ERR/s MIS/s
10:36:45 0 0.00 5.43 0.00 0.00 0.00 0.00 81.55 0.50 0.60 2.50 0.50 12.63 0.50 2.00 0.00 81.55 0.50 0.60 2.50 0.50 12.63 0.50 1.50 134.87 16949.32 3.25 2.62 3.55 1.32 17720.62 7.03 7.35 3.58 1.63 6.73 3.53 4.48 5.33 1.37 1.42 0.83 10.58 0.52 0.00 90.33 16160.05 3.72 2.07 0.73 0.73 0.82 2.53 17669.83 7.23 7.23 2.17 1.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.50 0.05.00 0.05.00 0.00 0.00 0.00 0.00 0.05 0.05 0.00 0.00 0.00 0.00 0.00 4.04 4.0.00 0.00 0.00 0.00 0.00 0.00 0 0。00 0.00 0.02 0.00 0.00

10:35:45 CPU HI/s TIMER/s NET_TX/s NET_RX/s BLOCK/s BLOCK_IOPOLL/s TASKLET/s SCHED/s HRTIMER/s RCU/s
10:36:45 0 0.00 1000.05 2.93 56777.58 0.00 0.00 0.57 285.15 0.00 1313.05
...

测试条件：

  1. 流量速率：50000 fps
  2. 应用程序使用taskset命令绑定到CPU 1
  3. 所有中断（与以太网接口相关）都绑定到 CPU 0。

正如我们所见，“%soft”在 CPU 0 上显着增加：12.91% -> 52.79%。但是 NET_RX/s 减少了：62813.75 -> 56777.58。

我们还尝试使用 perf 实用程序分析 CPU 0。不幸的是，没有找到任何线索。

  • 内核 3.4
# perf stat -C 0 -e irq:softirq_entry,irq:softirq_exit,irq:softirq_raise -a sleep 60

 “睡眠 60”的性能计数器统计信息：

           3690739 irq:softirq_entry [100.00%]
           3691328 irq:softirq_exit [100.00%]
           4366035 中断：softirq_raise                                           

      60.020019821 秒时间过去
# perf stat -C 0 -d -a sleep 60

 “睡眠 60”的性能计数器统计信息：

      59978.442551 任务时钟 # 0.999 CPU 使用 [100.00%]
            138638 上下文切换 # 0.002 M/秒 [100.00%]
              4206 CPU 迁移 # 0.070 K/秒 [100.00%]
             91404 页面错误 # 0.002 M/sec                  
       49824470562 周期 # 0.831 GHz [49.34%]
       32279104677stalled-cycles-frontend #64.79% 前端周期空闲 [48.20%]
    停滞的周期后端  
       41765280058 指令 # 0.84 insns 每周期        
                                             # 每个insn 0.77 个停滞周期[62.35%]
        6939461584 个分支#115.699 M/sec [62.90%]
          69255081 分支未命中 # 所有分支的 1.00% [61.90%]
       13778063320 L1-dcache-loads #229.717 M/sec [63.72%]
         757751494 L1-dcache-load-misses # 所有 L1-dcache 命中的 5.50% [63.85%]
         153774796 LLC 负载 # 2.564 M/秒 [50.09%]
    LLC-负载未命中         

      60.065977609 秒时间过去
  • 内核 4.1
# perf stat -C 0 -e irq:softirq_entry,irq:softirq_exit,irq:softirq_raise -a sleep 60

 'CPU(s) 0' 的性能计数器统计信息：

           3540101 irq:softirq_entry (100.00%)
           3540380 irq:softirq_exit (100.00%)
           4365512 中断：softirq_raise                                           

      60.061923392 秒时间过去

# perf stat -C 0 -d -a sleep 60

 'CPU(s) 0' 的性能计数器统计信息：

      60105.618981 task-clock (msec) # 1.001 CPUs used (100.00%)
            112358 上下文切换 # 0.002 M/秒 (100.00%)
              3042 次 CPU 迁移 # 0.051 K/秒 (100.00%)
             23077 页面错误 # 0.384 K/秒                  
       69596616908 周期 # 1.158 GHz (44.44%)
       47063269010stalled-cycles-frontend #67.62% 前端周期空闲 (44.43%)
         停滞的周期后端   
       47882140206 指令 # 0.69 insns 每周期        
                                                  # 每个insn 0.98 个停滞周期（55.54%）
        8644786229 个分支# 143.827 M/sec (55.54%)
          82066359 分支未命中 # 占所有分支的 0.95% (55.55%)
       15150062571 L1-dcache-loads #252.057 M/sec (44.45%)
         891694267 L1-dcache-load-misses # 所有 L1-dcache 命中的 5.89% (22.23%)
         192155955 LLC 负载 # 3.197 M/秒 (22.23%)
            148469 LLC-load-misses # 所有 LL-cache 命中的 0.08% (33.33%)

      60.062744860 秒时间过去

也许，有人面临类似的问题。任何意见和建议将不胜感激。

4

2 回答 2

1

在从 3.16 升级到 4.9 内核（即 Debian Jessie 到 Debian Stretch）时遇到了类似的问题。

UDP 的网络性能显着下降。

我们没有任何天才的闪光，这帮助我们找到了罪魁祸首。

但是，我们进行了一些调整，并且非常接近之前的性能：

1）使用RSS。将 CPU 内核静态分配给 NIC 接收队列。停止 irqbalance 服务。RPS 和 RFS 并没有比 RSS 在我们的案例中进一步提高性能，但它可能对您有用，具体取决于您的硬件。

2) 减少调度程序变为活动的时间间隔。我只是使用了这篇文章中的参数。

一些进一步的文献

于 2018-03-01T19:01:05.480 回答
0

可能的原因是减轻了幽灵和崩溃漏洞。尝试将“nospectrev2 nopti nopcid”作为内核的引导参数传递。请注意，此更改是潜在的安全漏洞。

于 2018-06-18T09:54:11.167 回答