时间戳

首页 > 解决方案 > uwsgi 侦听队列在重新加载时填充

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

问题描述

我在 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. 有一些相关的细节使这种情况有点奇怪：

我意识到我可以增加监听队列的大小，但这似乎是一种创可贴，而不是实际的解决方案。而且它只在重新加载期间填满（并且需要 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

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

标签： djangouwsgi

解决方案

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

至于为什么硬停止起作用而优雅停止不起作用 -它似乎进一步表明您的应用程序代码正在挂起。将发送一个优雅的停止SIGHUP，它允许在应用程序中清理资源。SIGINT并SIGTERM遵循“停止你现在正在做的事情并退出”的更严厉的指导方针。

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

  • 阻塞连接
  • 锁
  • 沿着sleep

祝你好运！

推荐阅读