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

祝你好运！