1 问题背景

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

 

2 原因分析

l  网卡配置

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

l  操作系统参数配置

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

l  应用程序调优

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

3 解决方案

3.1 网卡调优

3.1.1 中断绑核

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

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

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

【华为云技术分享】Nginx应用调优案例_华为云

我们在服务器中搭载了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  应用程序上需要明确架构差异,可充分利用编译选项、编程技巧进行调优。

作者:大猩猩@汪汪队