1 问题背景

nginx的应用程序移植到TaiShan服务器上，发现业务吞吐量没有达到硬件预期，需要做相应调优。

2 原因分析

l  网卡配置

该应用场景下网络吞吐量大，网卡的配置能对性能提升起到很大的作用。

l  操作系统参数配置

在更换操作系统后，原来的一些调优措施需要重新定制。

l  应用程序调优

从x86切换到arm之后，可以做一些代码层面、编译选项上的调优。

3 解决方案

3.1 网卡调优

3.1.1 中断绑核

中断亲和度描述为可以为特定中断提供响应的一组CPU，如果应用程序可以通过关联到相关的CPU，在相同的CPU上下文中处理接收到的数据包，则可以减少等待时间，提高CPU利用率。

因此，我们可以将处理网卡中断的CPU core设置在网卡所在的NUMA上，从而减少跨NUMA的内存访问所带来的额外开销，提升网络处理性能。

在这个案例中绑核拓扑如下所示：

我们在服务器中搭载了4块1822网卡，每个网卡使用了4个端口，每个端口设置了6个队列。整机有96个CPU逻辑核，与这96个队列一一绑定。

在应用程序上，我们也在nginx.conf中设置worker_processes为96。

3.1.2 使用网卡的TSO特性

TSO(TCP Segmentation Offload)将传出的TCP数据包的分片工作交给网卡来做，这样可以提高大量使用TCP协议传输数据的应用程序的性能。使用了TSO特性后，将为CPU减负，可有效降低发送端的CPU利用率。

我们可以使用ethtool来使能TSO特性：

# /sbin/ethtool –K <ethX> tso on

在这个案例中，我们启用了所有端口的TSO特性以实现更高的吞吐量。

3.1.3 中断聚合

中断聚合通过合并多个接收到的数据包中断事件，将其一起发送到单个中断中，从而减少了网卡生成的中断数量。

增加中断聚合参数将：

l   产生更少的中断。

l   降低CPU利用率。

l   增加响应延时。

l   提高整体吞吐量。

所以在这里我们增大了中断聚合相关参数。

修改方式

使用ethtool -C $eth方法调整中断聚合参数。其中参数“$eth”为待调整配置的网卡设备名称，如eth0，eth1等。

# ethtool -C eth3 adaptive-rx off adaptive-tx off rx-usecs N rx-frames N tx-usecs N tx-frames N

为了确保使用静态值，需禁用自适应调节，关闭Adaptive RX和Adaptive TX。

l   rx-usecs：设置接收中断延时的时间。

l   tx-usecs：设置发送中断延时的时间。

l   rx-frames：产生中断之前接收的数据包数量。

l   tx-frames：产生中断之前发送的数据包数量。

3.1.4 TCP协议参数调优

在测试过程中，我们通过perf trace工具捕捉到了sock:sock_exceed_buf_limit事件：

perf trace -e sock:sock_exceed_buf_limit -F 777

这表示内核TCP协议栈中的发送缓冲区已耗尽，发送缓冲区的内存大小成为阻塞应用程序性能的瓶颈。

在 EulerOS中，初始值如下所示：

# cat /proc/sys/net/ipv4/tcp_rmem

4096 87380 524288

# cat /proc/sys/net/ipv4/tcp_wmem

4096 16384 4194304

在这个案例中，我们设置成如下所示的值：

echo '4096 2097152 67108864' > /proc/sys/net/ipv4/tcp_rmem

echo '4096 2097152 67108864' > /proc/sys/net/ipv4/tcp_wmem

之后在测试过程中，没有再监控到sock:sock_exceed_buf_limit事件。

3.2 操作系统调优

我们使用 perf 工具来统计被测试进程的相关信息，发现上下文切换的频率很高，如下所示：

# perf  stat -p 60433

Performance counter stats for process id '60433':

          3,276.24 msec task-clock                #    0.530 CPUs utilized

            15,695      context-switches          #    0.005 M/sec

                 0      cpu-migrations            #    0.000 K/sec

             1,368      page-faults               #    0.418 K/sec

     6,505,263,989      cycles                    #    1.986 GHz

     2,843,350,035      instructions              #    0.44  insn per cycle

   <not supported>      branches

        24,768,205      branch-misses

       6.187155520 seconds time elapsed

我们进一步使用perf 工具来监控被测进程，查看其中调度最频繁的部分。

perf sched record -- sleep 1 -p 59467

perf sched script

perf sched latency -s max

我们发现 timer_tick 在 Taishan服务器中占了很高的调度时延，对比x86服务器数据如下所示：

Taishan：

timer_tick:(97) | 7.364 ms | 591 | avg: 0.012 ms | max: 1.268 ms | max at: 710>

X86：

timer_tick:(33) | 0.203 ms | 56 | avg: 0.007 ms | max: 0.211 ms | max at: 1890644.810729 s

查看Taishan服务器系统中的/proc/cmdline文件，发现其中包含了启动参数nohz = off，这表示在该系统中关闭了内核的nohz特性，这使得timer_tick切换变得更加频繁，增加了上下文切换的开销。为了解决该问题，我们在/boot/efi/EFI/euleros/grub.cfg中删除了该内核引导参数nohz = off。

3.3 应用程序调优

在搭载了鲲鹏处理器的Taishan服务器上，我们可以在编译过程中指定处理器、架构相关的编译选项来进行优化。

修改方式：

l   在Euler系统中使用HCC编译器，可以在CFLAGS和CPPFLAGS里面增加编译选项：

        -mtune=tsv110 -march=armv8-a

l   在其它操作系统中，可以升级GCC版本到9.10，并在CFLAGS和CPPFLAGS里面增加编译选项：

        -mtune=tsv110 -march=armv8-a

4 总结

综上，相关调优思路总结如下：

l  明确处理器和外设硬件差异，充分利用硬件特性。

l  明确操作系统差异，在不同应用场景下进行针对性的调优。

l  应用程序上需要明确架构差异，可充分利用编译选项、编程技巧进行调优。