uwsgi 监听队列在重新加载时填满
uwsgi listen queue fills on reload
我正在 运行在 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
当我们的流量很小时，我们的触摸重载似乎不正常，这是预料之中的还是我们有更根本的问题？
在 uwsgi 上有一个 harakiri 模式，它会定期杀死长 运行 进程以防止不可靠的代码挂起（并有效地关闭应用程序）。我建议在那里寻找您的进程被杀死的原因。
至于为什么硬停有效而优雅停止无效 -- it seems to further indicate your application code is hanging。优雅停止将发送 SIGHUP，这允许在应用程序中清理资源。 SIGINT 和 SIGTERM 遵循更严格的 "stop what you are doing right now and exit" 准则。
无论如何，归结为这不是 uwsgi 问题，而是您的应用程序代码中的问题。找出挂起的东西及其原因。由于您没有注意到 CPU 峰值；一些可能要看的地方是...
- 阻止连接
- 锁
- 一长
sleep
祝你好运！
您需要查看的关键是“套接字“127.0.0.1:8001”的侦听队列 (fd: 3) 已满 !!! (101/100)”
默认侦听队列大小为 100。通过在 uwsgi.ini 中添加选项“侦听”来增加队列大小。
“听 = 4096”
我正在 运行在 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
当我们的流量很小时，我们的触摸重载似乎不正常，这是预料之中的还是我们有更根本的问题？
在 uwsgi 上有一个 harakiri 模式，它会定期杀死长 运行 进程以防止不可靠的代码挂起（并有效地关闭应用程序）。我建议在那里寻找您的进程被杀死的原因。
至于为什么硬停有效而优雅停止无效 -- it seems to further indicate your application code is hanging。优雅停止将发送 SIGHUP，这允许在应用程序中清理资源。 SIGINT 和 SIGTERM 遵循更严格的 "stop what you are doing right now and exit" 准则。
无论如何，归结为这不是 uwsgi 问题，而是您的应用程序代码中的问题。找出挂起的东西及其原因。由于您没有注意到 CPU 峰值；一些可能要看的地方是...
- 阻止连接
- 锁
- 一长
sleep
祝你好运！
您需要查看的关键是“套接字“127.0.0.1:8001”的侦听队列 (fd: 3) 已满 !!! (101/100)”
默认侦听队列大小为 100。通过在 uwsgi.ini 中添加选项“侦听”来增加队列大小。
“听 = 4096”