Python中uwsgi长时间处理请求导致网站不可用怎么办？

nginx + uwsgi + django

uwsgi 配置了 4 个 worker，偶尔网站会打不开，装了一些 trace 工具分析后，发现不可用的时候，uwsgi 中的 1 个或者 2 个 worker，都是在处理一些耗时的任务，比如 requests 请求第三方 api。

所以表面上看好像是因为：某个 uwsgi worker 因为在处理某个耗时请求，然后某些 http request 如果正好分配到这个 uwsgi，那就不可用了？

但是另外还有 2 个 worker 是 idle 状态的呀，明明是可以提供工作的呀。

有点不理解？求指教，谢谢。
Python中uwsgi长时间处理请求导致网站不可用怎么办？


8 回复

给 nginx 设置超时时间和尝试下一个 upstream 的策略


遇到uWSGI处理长请求卡住整个站点的问题，核心是worker进程被阻塞了。最直接的解法是配置超时和优雅的重启机制。

关键配置在uWSGI的ini文件里加上这几项：

[uwsgi]
# 设置单个请求的超时时间（秒）
harakiri = 30
# 请求完成后重启worker，防止内存泄漏
max-requests = 1000
# 启用master进程管理worker
master = true
# 设置worker数量，根据CPU核心调整
workers = 4
# 每个worker同时处理的请求数
threads = 2

如果某些请求确实需要长时间运行（比如文件处理、复杂计算），应该用异步任务队列（Celery + Redis/RabbitMQ）来处理，不要放在web请求里同步执行。

简单说就是设超时、用异步。

这就是异步请求的应用场景了。
在请求中只负责分配任务，将耗时任务交给异步 worker 去执行，可以用 celery、gearman 或者自己写一个

看起来不像是长请求导致的。
看看 nginx 的 uwsgi_read_timeout 配置项，还有 nginx 的 error log

正在工作的话应该是不会分配到的。加到十个 worker 试试还有没有这个现象

hi，想请问下「尝试下一个 upstream 的策略」是哪个参数控制呢?

恩，明白，不过历史原因，没法立马解决。。


只有个别路径配置了 uwsgi_read_timeout=300，其他的都是默认。

你 trace 后才发现还有两个 backend 可用，可是 nginx 怎么知道呢……默认的策略就是轮询呀
1. 你需要先解决那个长耗时请求的问题（合理设置超时，或者解决慢查询的问题），一共就 4 个 worker，hang 住了 2 个，50%的处理能力就没有了，这种严重影响吞吐的问题是根本问题
2. 如果认为这样的情况是符合你的预期的，那么处理一下 nginx 的超时，因为上一个从 nginx 来的请求可能已经因为超时断开了，nginx 认为后端已经是 idle 的状态，于是又把请求发给了这个 backend，调整一下超时，让 nginx 的超时大于你这个场景的处理时间
3. 如果还认为这种情况是符合你的预期的…… proxy 还有配置重试的指令，但不解决上面长耗时的问题，大概率的可能是把 4 个 worker 都变成 hang 住的状态，这个时候重启服务解决一切问题……最终还是要回到 1
简单看一下雪崩和吞吐量相关的介绍就大致明白这个模型了

很感谢哥们的解释，这下子我的思路也清晰多了。确实 nginx 不像 lvs 那边有 health check，所以 nginx 并不知道 uwsgi 的 2 个 worker 已经 hang 了。

真的感谢！

回到顶部