nginx + spring cloud 大量并发时 nginx 502 错误
BenchWidth · 2023-01-12 10:42:24 +08:00 · 1231 次点击这是一个创建于 686 天前的主题，其中的信息可能已经有所发展或是发生改变。
服务架构 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 后，服务并没有崩溃，高峰过了后一会儿就自动恢复正常了。
请问大佬们，出现这种情况都是怎么解决的呢？
 |
1
youzi0516 2023-01-12 11:25:54 +08:00
3000 并发 gateway 几个副本啊 显然 不够用 瓶颈根本不在 ng
|
 |
2
seers 2023-01-12 11:46:38 +08:00 via Android
检查 Nginx 配置，是不是限制了 upstream 连接数
|
 |
3
daye 2023-01-12 12:02:26 +08:00
瓶颈大概率不是 nginx ，而是 gateway 网关层或业务接口
|
 |
4
perfectlife 2023-01-12 12:26:10 +08:00 via Android
这不是后端响应超时嘛，单看系统监控没啥用，你还得看下 jvm ，网关 3 大概率内存爆了
|
|
5
daye 2023-01-12 12:30:10 +08:00
no live upstreams 有可能是因为 nginx 负载均衡转发服务的请求连续报错或者拒绝服务，然后被 nginx 标记为不可用接着会失败重试其他节点，如果全部负载均衡节点都被标记，则直接返回 502
|
|
6
daye 2023-01-12 12:34:40 +08:00
你可以写个简单的后端接口，不做任何处理，接到请求直接返回响应，再对该接口进行压测，看同样并发会不会出现 502
|
|
7
daye 2023-01-12 12:35:18 +08:00
如果没有 502 ，则瓶颈不在 nginx
|
|
8
daye 2023-01-12 12:37:24 +08:00
如果还有 502 的话，再缩减范围，在网关层就直接响应返回，再压测试试
|
 |
9
sujin190 2023-01-12 13:51:59 +08:00
3000 并发已经很高了，200-400ms 延时，每秒 qps 过万了吧，502 估计就是 #5 楼说的问题，网关无响应被标记为不可用节点了，3000 并发已经是很高的值了，每个请求都要查询数据库的话，想不超时估计需要各种优化了
|
 |
10
BenchWidth OP @perfectlife 网关 3 内存没有爆，只是阿里云没有展示出来，服务都是正常的
@daye 经过了一系列排查暂时定位在了 nacos 的服务发现上，nacos 使用的版本是 1.3 性能不高，并且 nacos 没有做集群，在查询一些列文章后，简单总结了一下大概的意思是。1.*的 nacos 并发率不高，2.*的 nacos 有 10 倍的性能提升。现在正在尝试升级 nacos 看看是否能够解决问题。 @sujin190 qps 最高有在 2w 多，由于业务原因，经常会出现短时间内并发数剧增的情况。 @seers nginx 没有限制 upstream 的连接数 |
|
11
sujin190 2023-01-13 13:57:50 +08:00
@BenchWidth #10 没懂 nacos 还能影响这？也不是每个请求都需要请求 nacos 吧，那 nacos 应该和并发无关才对
如果有经常会出现短时间内并发数剧增的情况，建议限流，服务有最佳处理延时和 qps ，限流排队要比直接打到服务上效率要高得多，可以测测看，一般一个节点给 64-256 并发应该就最佳了，而且入股是短时限流排队更有利于削峰吧 |
Select Language