nginx + spring cloud 大量并发时 nginx 502 错误

2023-01-12 10:42:24 +08:00
 BenchWidth

服务架构 nginx + spring cloud + redis + mysql

nginx (4 vCPU 8 GiB)

网关 1 (4 vCPU 8 GiB)

网关 2 (4 vCPU 8 GiB)

网关 3 (8 vCPU 16 GiB)

上述服务器除了 nginx 是 20mb 带宽其他都是 1mb 带宽走的阿里云内网

其他 cloud 服务,负载均正常,没有出现错误日志。

数据库使用的是阿里云的 rds 8 核 mysql 5.7

redis 内存占用 800mb

自己压力测试结果

1 、直接连接网关进行接口测试 3000 并发时会出现接口无法响应的情况

2 、从 nginx 进行均衡负载后在 1000 并发时就会出现 nginx 返回 502 的情况 错误日志报错 no live upstreams while connecting to upstream

下面是压力测试接口,单次请求详情,也是 nginx 出现 502 时大量用户请求的接口之一。

Load time:1052
Connect Time:932
Latency:1042
Size in bytes:38847
Sent bytes:260
Headers size in bytes:173
Body size in bytes:38674
Sample Count:1
Error Count:0
Data type ("text"|"bin"|""):text
Response code:200
Response message:OK


HTTPSampleResult fields:
ContentType: application/json
DataEncoding: null

接口数据是做了 redis 缓存的。

尝试过的配置,


修改服务器内核配置 /etc/sysctl.conf

net.ipv4.tcp_max_tw_buckets = 262144
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_syn_retries = 1
net.ipv4.tcp_slow_start_after_idle = 0

还有一些配置 nginx 的 max_fails 重试次数以及配置 keepalive_timeout 超时时间等,都没有改善这个问题。

出现 502 后,服务并没有崩溃,高峰过了后一会儿就自动恢复正常了。

请问大佬们,出现这种情况都是怎么解决的呢?

1258 次点击
所在节点    问与答
11 条回复
57L49t45Jo9IJvge
2023-01-12 11:25:54 +08:00
3000 并发 gateway 几个副本啊 显然 不够用 瓶颈根本不在 ng
seers
2023-01-12 11:46:38 +08:00
检查 Nginx 配置,是不是限制了 upstream 连接数
daye
2023-01-12 12:02:26 +08:00
瓶颈大概率不是 nginx ,而是 gateway 网关层或业务接口
perfectlife
2023-01-12 12:26:10 +08:00
这不是后端响应超时嘛,单看系统监控没啥用,你还得看下 jvm ,网关 3 大概率内存爆了
daye
2023-01-12 12:30:10 +08:00
no live upstreams 有可能是因为 nginx 负载均衡转发服务的请求连续报错或者拒绝服务,然后被 nginx 标记为不可用接着会失败重试其他节点,如果全部负载均衡节点都被标记,则直接返回 502
daye
2023-01-12 12:34:40 +08:00
你可以写个简单的后端接口,不做任何处理,接到请求直接返回响应,再对该接口进行压测,看同样并发会不会出现 502
daye
2023-01-12 12:35:18 +08:00
如果没有 502 ,则瓶颈不在 nginx
daye
2023-01-12 12:37:24 +08:00
如果还有 502 的话,再缩减范围,在网关层就直接响应返回,再压测试试
sujin190
2023-01-12 13:51:59 +08:00
3000 并发已经很高了,200-400ms 延时,每秒 qps 过万了吧,502 估计就是 #5 楼说的问题,网关无响应被标记为不可用节点了,3000 并发已经是很高的值了,每个请求都要查询数据库的话,想不超时估计需要各种优化了
BenchWidth
2023-01-12 16:09:58 +08:00
@perfectlife 网关 3 内存没有爆,只是阿里云没有展示出来,服务都是正常的

@daye 经过了一系列排查暂时定位在了 nacos 的服务发现上,nacos 使用的版本是 1.3 性能不高,并且 nacos 没有做集群,在查询一些列文章后,简单总结了一下大概的意思是。1.*的 nacos 并发率不高,2.*的 nacos 有 10 倍的性能提升。现在正在尝试升级 nacos 看看是否能够解决问题。

@sujin190 qps 最高有在 2w 多,由于业务原因,经常会出现短时间内并发数剧增的情况。

@seers nginx 没有限制 upstream 的连接数
sujin190
2023-01-13 13:57:50 +08:00
@BenchWidth #10 没懂 nacos 还能影响这?也不是每个请求都需要请求 nacos 吧,那 nacos 应该和并发无关才对

如果有经常会出现短时间内并发数剧增的情况,建议限流,服务有最佳处理延时和 qps ,限流排队要比直接打到服务上效率要高得多,可以测测看,一般一个节点给 64-256 并发应该就最佳了,而且入股是短时限流排队更有利于削峰吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/908350

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX