我使用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-tracebacker获取每个worker / thread的堆栈跟踪时，我得不到答案。这些流程只是挂起。
我怎样才能研究究竟是什么让uwsgi进程挂起？
我怎样才能防止这种情况发生？
我知道harakiri参数但我不确定如果进程有其他活动线程，该进程是否被终止。
PD：＆＃34;重新加载怜悯＆＃34;设置为一个非常高的值避免杀死仍然活动线程的工作者（似乎是一个错误）。我们有一些Web请求仍然需要很长时间（这些请求将转换为作业）。
提前致谢。
答案 0 :(得分：1)
虽然我已经添加了评论，但这里有更长的描述。
警告：只有在使用多个工作进程和多个线程（-p --threads）时才会出现问题。
简短版本：在Python 2.7.x中，某些模块在导入期间不是100％线程安全的（日志记录，隐式导入的编解码器）。尝试在给予uwsgi的wsgi文件中导入所有这些有问题的模块（即，在uwsgi forks之前）。
长版：在https://github.com/unbit/uwsgi/issues/1599我分析了问题，发现它可能与python bug with the logging module有关。问题可以解决导入和初始化任何关键模块之前uwsgi forks，这是在执行uwsgi的wsgi脚本之后发生的。
我终于解决了直接或间接从wsgi文件导入django settings.ROOT_URLCONF的问题。这也有减少内存消耗的好处（因为工作者之间共享的代码库要大得多）和每个工作者的初始化时间。