uwsgi 侦听队列在重新加载时填充

Question

我在 uwsgi 上运行一个 Django 应用程序，在高峰时段平均有 110 个并发用户和每秒 5 个请求。我发现当我在这些高峰时段使用uwsgi reload 进行部署时，我开始遇到一个问题，即工作人员不断被缓慢杀死并重新启动，然后 uwsgi 日志开始抛出错误：

Gracefully killing worker 1 (pid: 25145)...
Gracefully killing worker 2 (pid: 25147)...
... a few minutes go by ...
worker 2 killed successfully (pid: 25147)
Respawned uWSGI worker 2 (new pid: 727)
... a few minutes go by ...
worker 2 killed successfully (pid: 727)
Respawned uWSGI worker 2 (new pid: 896)    
... this continues gradually for 25 minutes until:
*** listen queue of socket "127.0.0.1:8001" (fd: 3) full !!! (101/100) ***

此时，我的应用程序迅速变慢，我只能通过硬uwsgi stop 和uwsgi start 恢复。有一些相关的细节使这种情况有点奇怪：

• 只有在我uwsgi reload 时才会出现这种情况，否则监听队列永远不会自行填满
• 错误消息和减速仅在重新加载大约 25 分钟后才开始出现
• 即使在危机时刻，机器上的内存和 CPU 资源似乎也很好
• 如果我在交通较轻的时间部署，这个问题似乎不会弹出

我意识到我可以增加监听队列的大小，但这似乎是一种创可贴，而不是实际的解决方案。而且它只在重新加载期间填满（并且需要 25 分钟）这一事实让我相信它最终会填满，无论大小。我想弄清楚导致队列填满的机制并从源头解决这个问题。

相关uwsgi配置：

[uwsgi]
socket = 127.0.0.1:8001
processes = 4
threads = 2
max-requests = 300
reload-on-rss = 800
vacuum = True
touch-reload = foo/uwsgi/reload.txt
memory-report = true

相关软件版本号：

uwsgi 2.0.14
Ubuntu 14.04.1
Django 1.11.13
Python 2.7.6

当我们有少量流量时，我们的触摸重新加载似乎并不优雅，这是意料之中的还是我们有更根本的问题？

Answer 1

在 uwsgi 上有一个harakiri 模式，它会定期终止长时间运行的进程，以防止不可靠的代码挂起（并有效地关闭应用程序）。我建议在那里查找您的进程被杀死的原因。

为什么硬停止有效而优雅停止无效 -- it seems to further indicate your application code is hanging。优雅停止将发送SIGHUP，它允许在应用程序中清理资源。 SIGINT 和 SIGTERM 遵循“停止你现在正在做的事情并退出”的更严格的指导方针。

无论如何，归结为这不是uwsgi 问题，而是您的应用程序代码中的问题。找出挂起的内容以及原因。由于您没有注意到 CPU 峰值；一些可能的地方是......

• 阻止连接
• 锁
• 很长的sleep

祝你好运！

Answer 2

您需要查看的关键是“侦听套接字“127.0.0.1:8001”（fd：3）已满！！！（101/100）的队列”

默认监听队列大小为 100。通过在 uwsgi.ini 中添加选项“listen”来增加队列大小。

“听 = 4096”