Nginx 实战系列之三：Nginx TCP backlog 分析优化和性能相关经验汇总

Nginx TCP backlog 分析优化和性能相关经验汇总

Nginx TCP backlog 分析和优化

1，Nginx TCP backlog 配置说明

Nginx TCP backlog 配置，如果是同一个 listen 端口，设置一次就好；比如有多个 server，每个 server 都是监听 80 端口，只需要给一个 80 端口设置 backlog 就好，一般我们会有一个 default server，在default server 的 80 端口上设置 backlog 的值就可以了；设置好了之后，可以通过 ss -lnt 查看。

backlog 配置多少合适？推荐的 Nginx 的经验值是 4096 or 8192，当然，你也可以配置为好几万（一般不用），具体要看是否真有那么多 accept 队列。

2，Nginx backlog 队列满的排查和优化

ListenOverflows、ListenDrops

如果 accept 队列满了，那么就会导致 listen 的端口上出现 ListenOverflows 和 ListenDrops，这个可以通过 netstat -s 来进行统计和排查。

accept 队列满的优化

在我们有充分考虑实际情况、考虑 Nginx 对新连接的处理逻辑、网络状况（如往返时间）等因素之后：

• 合理的调大 Nginx Listen 的 backlog 参数，以免 accept 队列被塞满
• 比如 Nginx 的 listen 可以调到 8192
• 这个参数要小于等于 /proc/sys/net/core/somaxconn 这个内核参数
• 合理的调大内核参数 /proc/sys/net/core/somaxconn
• 每一个端口最大的 Listen 监听队列的长度，比如设置为 32768
• echo 32768 > /proc/sys/net/core/somaxconn
• 调大内核参数 /proc/sys/net/ipv4/tcp_max_syn_backlog
• SYN（待完成连接）队列长度
• echo 819200 > /proc/sys/net/ipv4/tcp_max_syn_backlog

Nginx 在线上运行中的一些性能相关经验汇总

• Nginx 本身的参数优化，大部分人都能做出一些优化处理；但是仅仅依靠 Nginx 本身的参数优化还无法达到我们的诉求；还必须要对 Linux 系统层面的优化有深入研究，这些优化上面都有说明。
• 实战中出现问题更多的，是 Linux 系统层面的，尤其是软中断和 nf_conntrack。
• Nginx 在实战中，一定要区分内网、外网，内外网进行分组隔离；也即是内网一组或者多组 Nginx 代理、外网一组或者多组 Nginx 代理
• 针对外网的 Nginx 代理，在大型互联网公司，我们都是需要加速卡的，如 Inter 的 QAT 加速卡，因为外网代理会有大量的 HTTPS 请求，加解密、压缩、计算等，可以大大减少 CPU 的开销，没有加速卡，Nginx 机器的 CPU 是扛不住的，如果大量增加 Nginx 机器，又浪费成本，因此，可以增加加速卡、减少 Nginx 机器来提高外网代理层的性能
• 要关注大包、小包的不同处理情况，对于小包，CPU 消耗会更多，因为软中断问题、解包头、校验包数据等层面的问题
• 短连接的场景下，CPU 的 si 更容易达到性能瓶颈
• 目前常规物理机机器，32 核 or 40 核的，一般内存在 32G 左右，网卡一般配置 1-2 个千兆网卡，这个机型，首先出现性能瓶颈点的，不会是 CPU，是网卡带宽
• 机器的合理选择和配置，对成本控制非常重要，这个是运维和架构师所需考虑的
• 尤其是，在公有云上的机型选择，一定要注意，选 CPU 和网卡最合适的
• Nginx 在 CPU 和 Nginx 本身参数等都优化过了之后，接下来的重点，就是日志，Nginx 的 access log 日志从实际情况来看，是必须要输出的，但是输出的话，又会大大影响性能，主要是受磁盘 IO 的性能影响。因此可以考虑如下两个姿势：
• 需要有大块内存，来当做 tmpfs
• 最后考虑使用 tmpfs
• 示例：access_log /www/logs/access.log main buffer=128k;
• 配置 buffer 一般可以提升 15-20% 左右，这个是最简单的优化方案
• 日志写 buffer，配置 buffer 指令，如buffer=128k
• 日志写内存文件系统 tmpfs
• 最后，从我的工作经验来看，初期最重要的是功能完备性和稳定性，后期才是性能优化的重点