uWSGI 工作人员卡住了：为什么答案

【问题标题】：uWSGI workers stuck: whyuWSGI 工作人员卡住了：为什么
【发布时间】：2017-06-29 12:58:09
【问题描述】：

我正在使用具有以下配置的 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 获取每个工作程序/线程的堆栈跟踪时，我没有得到任何答案。进程只是挂起。

我如何研究导致 uwsgi 进程挂起的确切事实是什么？

我怎样才能防止这种情况发生？

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

PD：“重新加载怜悯”设置为一个非常高的值，以避免杀死仍处于活动线程的工作人员（似乎是一个错误）。我们有一些 Web 请求仍然需要很长时间（正在转换为作业）。

提前致谢。

【问题讨论】：

你找到解决方案了吗？
是的，请参阅github.com/unbit/uwsgi/issues/1599。基本上，在 Python 2.7 中，一些 stdlib 模块（如日志记录）的导入可能不是线程安全的。所以我将导入移动到 wsgi 模块本身，这些模块在 uwsgi 分叉工人之前运行

标签： python multithreading uwsgi

【解决方案1】：

虽然我已经添加了评论，但这里有更长的描述。

警告：该问题仅在使用多个工作进程和多个线程 (-p --threads) 时出现。

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

长版：在https://github.com/unbit/uwsgi/issues/1599我分析了问题，发现可能和python bug with the logging module有关。该问题可以通过在执行给 uwsgi 的 wsgi 脚本之后发生的 uwsgi 分叉之前导入和初始化任何关键模块来解决。

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

【讨论】：