uwsgi 长时间处理一个请求，导致网站不可用？

[timchou]

nginx + uwsgi + django

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

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

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

有点不理解？求指教，谢谢。

[julyclyde]

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

[tonghuashuai]

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

[wcsjtu]

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

[doubleflower]

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

[timchou]

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

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


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

[troycheng]

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

[timchou]

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

真的感谢！