请教用 uwsgi listen queue 满了就无响应的问题

[xing393939]

api 接口项目使用 uwsgi，开始队列设为 1024，运行几个小时后服务就挂了。

用 uwsgitop 查看，lq=1025，uwsgi 日志也在报 listen queue of socket (fd 3) full (1025/1024)

网上查了资料，说是 uwsgi 有过载保护，listen queue 超过阈值就罢工（实在不能理解），于是修改 listen queue 为 9999，运行几个小时依旧会挂。

用 uwsgitop 查看，lq=8000 多，而且不断变大，预计又是要到了 10000 再罢工。

我就疑惑了，为什么 listen queue 没有达到阈值就开始罢工了，难道踩了其他的坑？

这个项目正常运行时，用 uwsgitop 查看 rqs 大概是 30，并发并不高，接口响应一般在 10ms，最慢也是 300ms，不知道有没有碰到类似问题的朋友？

[est]

listen 一般 200 就够用了。你这是堵了多少没处理过来的请求。。。还是贵站业务特别繁忙？

举个例子，

workers = 144
listen = 100

这个配置我 4 个物理机抗过 4w qps 的的峰值。

[jianjian001]

有阻塞，没释放链接？贴个 简化的 代码看看。

[arrow8899]

没有遇到过。
检查下代码吧，应该是哪里 hang 住了

[xing393939]

@est 如果 listen 设 100 都没问题，那大概是程序容易卡了，关键是这个问题不好排查和定位。

[xing393939]

@jianjian001 我简单说下程序吧，用的 flask+pymongo+redis，这三个都是单独的机器环境，从 zabbix 上看机器状态没有异常。接口逻辑也是比较简单的，先查 redis，没有则查 mongo。

[Lax]

queue 就是个水管子，出水口（程序处理能力）太小就容易堵。
看看为什么处理能力不行吧

[est]

@xing393939 设置 100 其实很夸张了。

假如你一个请求 10ms 完成（实际肯定不止这个数），那么 100 个 queue，最后一个请求也得 1s 之后才能开始处理。。。对用户而言这就是灾难吧。。你 1025 长度的 queue，最后一个请求就是 10s 之后才会处理了。。

看下接口平均响应时间呢。