性能优化之Nginx502

最新推荐文章于 2024-05-23 20:02:19 发布

老李说IT

最新推荐文章于 2024-05-23 20:02:19 发布

阅读量731

点赞数

分类专栏：服务器文章标签： nginx

本文链接：https://blog.youkuaiyun.com/scare125/article/details/109802509

版权

本文介绍了在进行性能压测时遇到的Nginx 502 Bad Gateway问题，分析了由于短连接导致的端口号耗尽现象，以及由此引发的CPU资源占用过高问题。通过查看Nginx日志，发现大量"Cannot assign requested address"错误，判断为TIME_WAIT连接过多。解决方案包括调整端口号范围、设置tcp_tw_reuse、增大tcp_max_tw_bucket以及考虑使用长连接。最后强调了理解Linux内核参数对线上问题排查的重要性。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

前言

事实证明，读过Linux内核源码确实有很大的好处，尤其在处理问题的时刻。当你看到报错的那一瞬间，就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。

首先，这个问题其实并不难解决，但是这个问题引发的现象倒是挺有意思。先描述一下现象吧，笔者要对自研的dubbo协议隧道网关进行压测(这个网关的设计也挺有意思，准备放到后面的博客里面)。先看下压测的拓扑吧:
为了压测笔者gateway的单机性能，两端仅仅各保留一台网关，即gateway1和gateway2。压到一定程度就开始报错，导致压测停止。很自然的就想到，网关扛不住了。
在这里插入图片描述

网关的情况

去Gateway2的机器上看了一下，没有任何报错。而Gateway1则有大量的502报错。502是Bad Gateway，Nginx的经典报错，首先想到的就是Gateway2不堪重负被Nginx在Upstream中踢掉。
在这里插入图片描述

那么，就先看看Gateway2的负载情况把，查了下监控，发现Gateway2在4核8G的机器上只用了一个核，完全看不出来有瓶颈的样子，难道是IO有问题？看了下小的可怜的网卡流量打消了这个猜想。

Nginx所在机器CPU利用率接近100%

这时候，发现一个有意思的现象,Nginx确用满了CPU!
在这里插入图片描述
再次压测，去Nginx所在机器上top了一下，发现Nginx的4个Worker分别占了一个核把CPU吃满-_-!

什么，号称性能强悍的Nginx竟然这么弱，说好的事件驱动\epoll边沿触发\纯C打造的呢？一定是用的姿势不对！

去掉Nginx直接通信毫无压力

既然猜测是Nginx的瓶颈,就把Nginx去掉吧。Gateway1和Gateway2直连，压测TPS里面就飙升了，而且Gateway2的CPU最多也就吃了2个核，毫无压力。

在这里插入图片描述

去Nginx上看下日志

由于Nginx机器权限并不在笔者手上，所以一开始没有关注其日志，现在就联系一下对应的运维去看一下吧。在accesslog里面发现了大量的502报错，确实是Nginx的。又看了下错误日志，发现有大量的

Cannot assign requested address
由于笔者读过TCP源码，一瞬间就反应过来，是端口号耗尽了！由于Nginx upstream和后端Backend默认是短连接，所以在大量请求流量进来的时候回产生大量TIME_WAIT的连接。
在这里插入图片描述
而这些TIME_WAIT是占据端口号的，而且基本要1分钟左右才能被Kernel回收。

cat /proc/sys/net/ipv4/ip_local_port_range
32768	61000

也就是说，只要一分钟之内产生28232(61000-32768)个TIME_WAIT的socket就会造成端口号耗尽，也即470.5TPS(28232/60),只是一个很容易达到的压测值。事实上这个限制是Client端的,Server端没有这样的限制，因为Server端口号只有一个8080这样的有名端口号。而在 upstream中Nginx扮演的就是Client,而Gateway2就扮演的是Nginx

最低0.47元/天解锁文章