Python uWSGI员工陷入困境：为什么

我正在使用uwsgi版本2.0.13.1，配置如下：

bin/uwsgi  -M -p 5 -C -A 4 -m -b 8192 -s :3031 --wsgi-file bin/django.wsgi --pidfile var/run/uwsgi.pid --touch-reload=var/run/reload-uwsgi.touch --max-requests=1000 --reload-on-rss=450 --py-tracebacker var/run/pytrace --auto-procname --stats 127.0.0.1:3040 --threads 40 --reload-mercy 600 --listen 200

（绝对路径名称已剪切）

当我运行

uwsgitop

时，所有5个工作进程都显示为忙碌。当我尝试使用py回溯器获取每个工作线程/线程的堆栈跟踪时，没有得到任何答案。这些过程只是挂起

我如何研究uwsgi进程挂起的确切原因

我怎样才能避免这种情况

我知道harakiri参数，但我不确定如果进程有其他活动线程，它是否会被终止

PD：“reload mercy”设置为一个非常高的值，以避免杀死仍处于活动状态的线程（似乎是一个bug）。我们有一些Web请求仍然需要很长时间（它们正在转换为作业）

---

提前感谢。

虽然我已经添加了一条评论，但这里有一个较长的描述

警告：只有在使用多个工作进程和多个线程（-p--threads）时，才会出现问题

简短版本：在Python2.7.x中，某些模块在导入（日志记录、隐式导入编解码器）期间不是100%线程安全的。尝试在提供给uwsgi的wsgi文件中导入所有此类有问题的模块（即，在uwsgi分叉之前）

长版本：在年，我分析了这个问题，发现它可能与。这个问题可以通过在uwsgi分叉之前导入和初始化任何关键模块来解决，而uwsgi分叉是在执行提供给uwsgi的wsgi脚本之后发生的

---

我最终解决了直接或间接从wsgi文件导入django settings.ROOT_URLCONF的问题。这还可以减少内存消耗（因为工作程序之间共享的代码库要大得多）和每个工作程序的初始化时间。

您得到解决方案了吗？是的，请参阅。基本上，在Python2.7中，一些stdlib模块（如日志记录）的导入可能不是线程安全的。因此，我将导入移动到wsgi模块本身，该模块在uwsgi分叉工人之前运行