zoukankan      html  css  js  c++  java
  • 【华为云技术分享】Nginx应用调优案例

    1 问题背景

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

    2 原因分析

    l  网卡配置

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

    l  操作系统参数配置

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

    l  应用程序调优

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

    3 解决方案

    3.1 网卡调优

    3.1.1 中断绑核

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

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

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

    1581304650499537.png

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

    作者:大猩猩@汪汪队

  • 相关阅读:
    了解一些常用的牛逼编译器(不限制编程语言, 不限制平台)
    Linux下的常用文本编辑器
    linux下一些重要命令的了解
    linux学习笔记(二:权限)
    liunx学习笔记(一:常用命令)
    文件操作相关的函数总结
    关于动态内存malloc和realloc
    实现一个简易的通讯录
    qsort函数排序各种类型的数据。
    结构体总结
  • 原文地址:https://www.cnblogs.com/2020-zhy-jzoj/p/13164921.html
Copyright © 2011-2022 走看看