云社区 博客 博客详情
云社区 博客 博客详情

Nginx应用调优案例

大猩猩@汪汪队 发表于 2020-02-10 11:18:41 02-10 11:18
大猩猩@汪汪队 发表于 2020-02-10 11:18:41 2020/02/10
0
0

【摘要】 1 问题背景nginx的应用程序移植到TaiShan服务器上,发现业务吞吐量没有达到硬件预期,需要做相应调优。 2 原因分析l 网卡配置该应用场景下网络吞吐量大,网卡的配置能对性能提升起到很大的作用。l 操作系统参数配置在更换操作系统后,原来的一些调优措施需要重新定制。l 应用程序调优从x86切换到arm之后,可以做一些代码层面、编译选项上的调优。3 解决方案3.1 网卡调优3.1.1...

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  应用程序上需要明确架构差异,可充分利用编译选项、编程技巧进行调优。


登录后可下载附件,请登录或者注册

【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区),文章链接,文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件至:huaweicloud.bbs@huawei.com进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容。
评论文章 //点赞 收藏 0
点赞
分享文章到微博
分享文章到朋友圈

评论 (0)


0/1000
评论

登录后可评论,请 登录注册

评论

您还没有写博客的权限!

温馨提示

您确认删除评论吗?

确定
取消
温馨提示

您确认删除评论吗?

删除操作无法恢复,请谨慎操作。

确定
取消
温馨提示

您确认删除博客吗?

确定
取消

确认删除

您确认删除博客吗?

确认删除

您确认删除评论吗?

温馨提示

登录超时或用户已下线,请重新登录!!!

确定
取消