【华为云技术分享】Nginx应用调优案例
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 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
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 应用程序上需要明确架构差异，可充分利用编译选项、编程技巧进行调优。
作者：大猩猩@汪汪队
作者：华为云