云端网络性能衰退分析和定位实战

By 高承博 金琦 刘唐 of TinyLab.org 2020/01/17

前言

用 iperf3 进行 udp 和 tcp 性能测试是云环境中很基本的性能测试，其中 udp 的带宽是评价虚机网络很重要的指标。

我们在 centos 两个不同版本中发现 iperf3 udp 网络性能测试结果出现差异，本文分析并定位了其原因，用到经典的 perf 和火焰图。

iperf3 网络性能测试

iperf3 是一套常见的网络吞吐量性能测试工具，本文用它来做网络性能测试。

iperf3 打 udp 64 字节小包命令

server 端

$ iperf3 -s -p 5672

参数解释如下：

• -s：作为 server 端
• -p 5672：表示端口号

client 端

$ iperf3 -c xxx.xxx.xx -t 100 -P 1 -u -b 5000M -l 64 -p 5672

参数解释如下：

• -c：作为 client 端
• -t 100：表示打流时间为 100 秒
• -P 1：表示几个 client 端并行打流
• -u：表示报文种类为 udp
• -b：表示带宽
• -l：报文数据长度（注意是数据长度，不是报文总长度）
• -p：填 server 端的监听端口号

测试环境

测试结果

centos 版本1 测试结果：

centos 版本2 测试结果：

可以看到，后者有较为明显的性能衰退。

定位过程

火焰图定位

火焰图命令

$ git clone https://github.com/cobblau/FlameGraph

// -p xxx: 为 iperf3 的进程号
$ perf record -F 99 -p xxx -g -- sleep 10

$ perf script | FlameGraph/stackcollapse-perf.pl | FlameGraph/flamegraph.pl > iperf3-xxx.svg

火焰图结果

centos 版本1火焰图：

centos 版本2火焰图：

火焰图分析

从 centos 版本2的火焰图可以看出在 __select 调用后有很大的空档，并且发现版本2火焰图的 system_call_fastpath 的占比明显少了很多，因此怀疑这可能是影响 iperf3 性能的关键。

glibc 前后都是一样的，可以排除。然后从 glibc 的 select 找到了内核的 select.c 文件中的 sys_select，而 system_call_fastpath 来自 sys_select，因此接下来重点排查这部分。

检查系统调用代码

system_call

在 X86 的体系架构里 glibc 通过系统调用把系统调用号放到 rax 寄存器，然后调用 syscall 指令进入内核态，这个细节不是本次讨论的重点。

本次关心的是内核的系统调用响应函数：system_call。

函数的代码 centos 中的版本中放在了 arch/x86/kernel/entry_64.S 中。

system_call 函数中执行了 system_call_fastpath 这个标签，很有可能是在 system_call 函数进入 system_call_fastpath 前做了一些操作导致了 system_call_fastpath 执行的时间变少。

出于此怀疑，继续对比一下两套 centos 版本内核的 system_call 代码。

内核代码对比

版本1代码：

版本2代码：

可以看到版本2在 system_call 代码中加入了：

IBRS_ENTRY /* no indirect jump allowed before IBRS */
FILL_RETURN_BUFFER /* no ret allowed before stuffing the RSB */

经过查询资料发现，这个跟当年 meltdown 漏洞相关。

还有一个是在 system_call_fastpath 中加入了：

#ifdef CONFIG_RETPOLINE
    movq sys_call_table(, %rax, 8), %rax
    call __x86_indirect_thunk_rax

经过查询资料发现，这个也是跟安全相关的一个补丁。

找到关键修改

接下来，逐个去掉版本2中的相应变更后，继续测试排除。

最终确认主要影响来自以下变更：

小结

以上详细演示了如何结合 perf 和火焰图来分析 iperf3 udp 网络性能衰退，希望对大家有所帮助。