一、问题现象
客户截屏系统偶发报错
后台排查nginx后台偶尔大量报错
no live upstreams while connecting to upstream
在nginx服务器上nestat查看
发现存在大量的 TIME_WAIT状态的连接
二、问题分析
问题表现在nginx与下游服务器的连接出现了异常，在突发流量以后由于TIME_WAIT状态的连接过多导致无法创建足够的连接。
为什么会有如此之多的TIME_WAIT呢？
我的分析是nginx中upstream与下游服务器之间要么是配置的短连接，要么是keepalive 的数量太少了。经过排查发现upstream中并无keepalive相关的配置。
如果nginx与下游服务器连接都是短连接的话，会频繁的创建和断开连接。每次断开连接都会导致连接处于TIME_WAIT一段时间才能被回收掉。
TIME_WAIT状态的持续时间是2MSL，2MSL的是时间还是比较长的，大概几十秒到几分钟。
当流量突增的时候，会出现大量无法回收的连接，最终导致新连接无法创建而报错。
如果nginx与下游服务器配置了长连接，但是upstream中keepalive很小的话也会出问题。
举个极端的例子:
假如nginx最多可以建10000个连接，keepalive的连接数配置的是1000个，即，对空闲连接最多可以维持1000个。空闲连接的回收时间为60秒。
在第一秒突然流量高峰，瞬间建了10000个连接，抗住了压力，没出什么大问题。然后在接下来的60秒，几乎没有什么流量访问，那么在此期间nginx会把9000个空闲连接给断开进行回收。但是回收中的连接会经历2MSL时间的TIME_WAIT。也就是说在此期间，这9000个连接是无法提供服务的。等到第61秒后，又来了一波流量高峰，需要建10000个连接才能抗住。这时就要出问题了，由于9000个连接无法有效回收，nginx只能拿出1000个连接应对请求，新建连接失败，后台报错。服务器上存在大量TIME_WAIT状态的连接。
三、配置修改
为了解决上面的问题，对nginx做了如下的配置调整后，问题解决。
经过若干天的观察问题得到了解决
四、nginx的容量分析
系统入口的平均响应时间大概是150毫秒
在http1.1的协议下，也就是说一个连接在1秒钟大概可以处理6.6个请求。
1000毫秒 / 150毫秒 = 6.6
如果nginx长期维持1000个活跃连接，每秒的QPS大概能到6600
当然流量突增的时候nginx还会新建连接，抗压能力应该会被6600要高。文章来源：https://www.toymoban.com/news/detail-489752.html
这只是在理论上粗略的思考一下自己的nginx的抗压能力。实际业务场景流量成分的差异、nginx连接的回收和复用，网络拥塞情况，等等都会对nginx的性能产生很大的影响。文章来源地址https://www.toymoban.com/news/detail-489752.html
到了这里，关于nginx偶发502 no live upstreams while connecting to upstream的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
![NGINX [upstream timed out (110: Connection timed out) while reading response header from upstream]错误](https://imgs.yssmx.com/Uploads/2024/02/610275-1.png)
![解决nginx: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)以及nginx 502 Bad Gateway解决方法](https://imgs.yssmx.com/Uploads/2024/02/481646-1.png)
