uswgi -无法从multiprocessing.semaphore_tracker加载配置

Question

目前，我正在将Flask应用程序部署到Ubuntu服务器(AWS)。当我尝试启动uwsgi服务器并使用journalctl查看日志时，我注意到一种警告/错误。

我可以忽略它吗？我不知道如何解决它，也不知道它是从哪里来的。现在已经坚持了两天了。有谁能帮帮我呢？

错误：

 *** Operational MODE: preforking ***
Jan 04 15:27:11 ip-172-31-39-12 uwsgi[21781]: unable to load configuration from from multiprocessing.semaphore_tracker import main;main(10)

Answer 1

在我的例子中，这个错误是由于使用uWSGI 2.0.17.1和Flask 1.0.2和scikit-learn 0.20.0造成的。

在内部，scikit-learn导入了joblib，它在导入时尝试产生一个信号量跟踪进程(sklearn/externals/joblib/_multiprocessing_helpers.py).

信号量跟踪过程是通过生成一个带有当前可执行文件名称的命令，并从multiprocessing.semaphore_tracker导入main;main(fd)"中附加“-c‘来实现的。

当前可执行文件的名称应为'python‘，但在使用uWSGI时并非如此。生成的命令是"/usr/local/bin/uwsgi -c 'from multiprocessing.semaphore_tracker import main;main(fd)"，该命令失败并输出上述错误消息。

如here文档所述，一种解决方法是设置环境变量JOBLIB_MULTIPROCESSING=0。

请注意，在我的情况下，这样做的唯一后果是生成一个废弃的uWSGI进程，该进程最终被清除。

Answer 2

您很想从应用程序内部(或从您正在使用的库)生成子进程。根据这一点，还产生了一个额外的协进程-信号量跟踪器，负责将您的子进程创建的所有命名信号量返回给系统。这是一项重要的任务，因为如果命名信号量泄漏(而不是删除)，相关的系统资源将被占用，直到下一次重新启动。

由于这些资源位于共享内存中，因此系统对这些资源具有有限数量的。如果您确定您的应用程序使用的命名信号量的数量并不重要，那么您可以忽略这一点。

请注意，多处理模块中定义的每种类型的锁都是幕后的命名信号量。此外，multiprocessing.Queue、Barier等的每个实例都实例化了自己的锁。

例如，如果您正在派生许多进程(工作进程)，并且每个进程都在实例化multiprocessing.Lock或multiprocessing.RLock，则泄漏(未删除)的命名信号量的数量可能会很大，从而快速耗尽限制，导致您的应用程序或其他应用程序耗尽资源。

以下是这些问题的解释链接：https://docs.python.org/3/library/multiprocessing.html?highlight=semaphore%20tracker#contexts-and-start-methods

Answer 3

嘿，我一直在努力解决同样的问题，虽然我不知道如何真正阻止弹出的特定信号量警告，但更改一些uWSGI选项已经帮助改善了这个问题。

我的.ini配置文件如下：

[uwsgi]
module = wsgi:app

master = true
processes = 16

socket = api.sock
chmod-socket = 660
vacuum = true

harakiri = 30
die-on-term = true
max-requests = 3

我添加的是"harakiri“和"max-request”选项。harakiri选项意味着如果一个请求超过30秒，工人将回收自己，最大请求选项意味着在三个请求之后，工人将回收自己。它似乎起作用了，所以我的理论是，虽然信号量可能不会被跟踪，但它们在某种程度上与工人联系在一起，定期回收它们可以提高性能。

这是一个内存泄漏的“愚蠢的战斗”，我希望我有一个更优雅的解决方案，但在过去的几天里我一直在为我工作。祝好运!