uwsgi worker在重生后保持空闲

Question

环境

• 操作系统：Linux (4.15.0-1043-aws) / Ubuntu 18.04.1 LTS 64 位
• Python：3.6.5（默认，2018 年 4 月 1 日，05:46:30）
• uwsgi: 2.0.17.1
• 应用服务器：Django 2.1.1
• Web 服务器：nginx/1.14.0 (Ubuntu)

问题

我使用nginx + uwsgi + django 设置Web 服务器，有时我发现响应太慢，我不得不使用uwsgi 提供的touch command 重新加载服务器。

使用uwsgitop监控我的uwsgi服务器后，我发现有一些uwsgi workers在重生后一直处于空闲状态，而这些worker的RSS和VSZ为零，如下图所示。

我在uwsgi日志中没有发现任何错误信息，生成信息是这样的正常：

worker 6 killed successfully (pid: 14872)
Respawned uWSGI worker 6 (new pid: 5545)

worker 9 killed successfully (pid: 14878)
Respawned uWSGI worker 9 (new pid: 3807)

如果我使用kill -9 worker-pid 命令重生工人，大多数时候工人可以成功重生并拥有RSS 和VSZ 并开始工作，而有时只是以零重生RSS 和VSZ并保持闲置。

我尽了最大的努力，但我不知道重生的工人发生了什么。我向uwsgi项目发了一个问题，但是很长时间没有得到回应（应该不是uwsgi的问题）。

对调试或检查此问题有何建议？

仅供参考，这是我的 uwsgi 配置：

# uwsgi.ini file
[uwsgi]

# deploy root
deploy_root     = /my/server/path

# Django-related settings
# the base directory (full path)
chdir           = %(deploy_root)/
# Django's wsgi file
module          = MyServer.wsgi
# the virtualenv (full path)
home            = %(deploy_root)/env/

# process-related settings
# master
master          = true
# maximum number of worker processes
processes       = 10
# socket listen queue size,default 100
listen          = 1024
# respawn processes taking more than 300 seconds
harakiri        = 300
# respawn processes after serving 5000 requests
max-requests    = 5000
# the socket (use the full path to be safe
socket          = %(deploy_root)/nginx_uwsgi/server.sock
# ... with appropriate permissions - may be needed
chmod-socket    = 666
# clear environment on exit
vacuum          = true
# run background with log file
daemonize      = %(deploy_root)/nginx_uwsgi/logs/uwsgi.log
# use pid file to stop uwsgi easily
pidfile        = %(deploy_root)/nginx_uwsgi/uwsgi.pid
# use utf8
env            = PYTHONIOENCODING=UTF-8
# use threads
enable-threads = true

# stats socket (use the full path to be safe)
stats          = %(deploy_root)/nginx_uwsgi/stats.sock
# show memory resources uwsgi processes are consuming
memory-report  = true

Answer 1

正如我在uwsgi issueSome worker keep idle after respawning上的cmets显示的那样，这个问题是由第三方模块APScheduler引起的。

我使用strace和gdb工具检查idle worker，发现idle worker刚刚卡在Waiting for the GIL。

所以我认为这应该是由我在主进程中创建的线程引起的。我在主进程中引入的唯一线程是APScheduler background instance，它用于启动 cron 作业。

在我将调度程序作业逻辑移动到一个单独的进程后，这个问题就再也不会发生了。