uWSGI工作进程卡住：为什么？

Question

我正在使用版本为2.0.13.1的uwsgi，并使用以下配置：

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 参数，但不确定如果进程有其他活动线程，是否会被杀死。

附注： "reload mercy" 设置为非常高的值，以避免对仍有活动线程的工作进程进行终止处理（似乎是错误）。我们有一些 Web 请求需要很长时间才能完成（正在努力转换为任务）。

谢谢。

- erny

---

你解决它了吗？ - Abhishek J

是的，请参见https://github.com/unbit/uwsgi/issues/1599。基本上，在Python 2.7中，一些stdlib模块（如logging）的导入可能不是线程安全的。因此，我将这些导入移动到了wsgi模块本身中，在uwsgi分叉工作进程之前运行。 - erny

Answer 1

尽管我已经添加了评论，但这里有一个更长的描述。

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

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

详细版本：在https://github.com/unbit/uwsgi/issues/1599中，我分析了问题，并发现它可能与记录模块的Python错误有关。可以通过在uwsgi分叉之前导入和初始化任何关键模块来解决该问题，而uwsgi分叉是在执行提供给uwsgi的wsgi脚本之后发生的。

我最终通过直接或间接从wsgi文件中导入django settings.ROOT_URLCONF来解决我的问题。这也有助于减少内存消耗（因为工作进程之间共享的代码库更大）和每个工作进程的初始化时间。

- erny