为什么uwsgi工作人员闲置但是nginx显示了很多超时？

Question

Stack：nginx，uwsgi，django

uwsgitop和top都表明uwsgi工作者是空闲的，而nginx错误日志表示上游超时。

我认为某些请求需要大量资源，例如等待数据库或缓存，而其他资源则不需要。在检查超时请求后，他们中的大多数都没有贪婪。任何形式的请求都已超时。

那么，如果其他人真的很忙，为什么nginx没有将请求播种到空闲的？为什么uwsgi大师只是让某人忙碌而其他人闲着？

Answer 1

我想回答我自己的问题。

将内核参数：net.ipv4.ip_conntrack_max从65560更改为6556000

我有一个关于我们如何找到答案的完整故事：

1. 用户说慢，慢，慢

2. nginx充斥着“上游连接超时”

3. 我检查了uwsgi日志，发现了一些错误，修复了它;发现更多，修复更多，这个循环持续了几天。直到昨天，我认为与uwsgi，memcached，db，redis或任何后端无关，因为uwsgi闲置

4. 所以我认为nginx肯定有错误，重新加载，重新启动，检查连接，工作人员，proxy_read_timeout等等没有运气。

5. 检查了ulimit -n，它报告了1024，默认值为1。我有8个nginx工作者，所以连接应达到1024 * 8，我认为这可能没问题，因为nginx从未说过太多打开的文件。无论如何，我把它改为4096.没有运气。

6. 检查连接号码，然后显示状态，然后出现问题。上游连接都处于syn_sent状态，然后超时发生。 300个连接中只有2个或3个处于已建立状态。我们想知道原因。我的一个朋友告诉我使用tcpdump，这是我从未敢尝过的神奇工具。

7. 然后我们转到syslog并发现以下错误，最后我们解决了问题

Answer 2

我有一个类似的问题，尽管所有工人都闲着，我的听众队列却在增加，并且RPS很低。

塞缪尔（Samuel）发现了其中一种情况，但这种行为还有更多潜在原因：

• net.core.somaxconn不够高
• uwsgi --listen不够高
• nginx worker进程过低
• nginx工作者连接太低

如果这些都不起作用，那么您将需要检查日志，以确认对uWSGI的入站请求位于http / 1.1之下，而不是http / 1.0下，然后使用--http11-socket

当我为这个问题而苦恼时，有一些发现：https://wontonst.blogspot.com/2019/06/squishing-performance-bug-in.html

nginx调整页面还具有一些其他配置，这些配置可能或可能对解决此问题没有帮助： https://www.nginx.com/blog/tuning-nginx/