堆栈：nginx、uwsgi、django
uwsgitop 和 top 都显示 uwsgi worker 处于空闲状态，而 nginx 错误日志显示上游超时。
我认为某些请求需要大量资源，例如等待数据库或缓存，而其他请求则不需要。在检查了超时请求后，它们中的大多数都不是贪婪的。任何类型的请求都已超时。
那么，如果其他人真的很忙，为什么 nginx 不将请求播种到空闲的请求呢？为什么uwsgi大师只是让某人忙而其他人闲着？
问问题
2623 次
2 回答
9
我想回答我自己的问题。
将内核参数：net.ipv4.ip_conntrack_max 从 65560 更改为 6556000
我有一个关于我们如何找到答案的完整故事：
用户说慢，慢，慢
nginx 充斥着“上游连接超时”
我检查了 uwsgi 日志，发现了一些错误，修复了它；发现更多，修复更多，这个循环持续了好几天。直到昨天，我还认为与 uwsgi、memcached、db、redis 或任何后端无关，因为 uwsgi 处于空闲状态
所以我认为 nginx 一定有问题，重新加载，重新启动，检查连接，workers，proxy_read_timeout 等等。没有运气。
检查 ulimit -n，它报告 1024，默认值。我有 8 个 nginx 工作人员，所以连接数应该达到 1024 * 8，我认为这可能没问题，因为 nginx 从来没有说过太多打开的文件。无论如何，我将其更改为 4096。没有运气。
检查连接数和状态，然后出现问题。上游连接都处于 syn_sent 状态，然后超时发生。300 个连接中只有 2 或 3 个处于已建立状态。我们想知道为什么。我的一位朋友告诉我使用 tcpdump，这是我一次都不敢尝试的神奇工具。
然后我们去syslog发现如下错误，最后我们解决了问题
于 2012-11-14T16:03:47.843 回答
0
我有一个类似的问题，我的监听队列在增长，尽管所有工作人员都处于空闲状态，但 RPS 很低。
samuel 发现了其中一种情况，但这种行为还有其他一些潜在原因：
- net.core.somaxconn 不够高
- uwsgi
--listen不够高 - nginx 工作进程太低
- nginx worker 连接太少
如果这些都不起作用，那么您需要检查您的日志，确认对 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/
于 2019-06-28T22:30:09.173 回答