Question

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

我可以忽略它吗？我不知道如何解决它或它来自哪里。现在已经坚持了2天。谁可以帮助我？

错误：

 *** 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

在我的情况下，此错误是由于在Flask 1.0.2和scikit-learn 0.20.0中使用了uWSGI 2.0.17.1。

在内部，scikit-learn导入joblib，该lib在导入时试图产生信号量跟踪过程（sklearn / externals / joblib / _multiprocessing_helpers.py）。

通过生成具有当前可执行文件名称的命令并附加“-c'from multiprocessing.semaphore_tracker import main; main（fd）” 来产生信号量跟踪过程。

当前可执行文件的名称应为“ 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，则泄漏（未删除）的命名信号的数量可能会很大，< strong>迅速耗尽限制，导致您的应用或其他资源用尽。

以下是对这些问题的解释的链接：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秒，则工作人员将自行回收，max request选项表示在三个请求之后，工作人员将自行回收。这似乎是可行的，所以我的理论是，尽管可能无法找到这些信号量，但它们还是以某种方式与工人联系在一起，并且定期回收它们可以提高性能。

这是一次内存泄漏的“哑巴斗争”，我希望我有一个更优雅的解决方案，但是最近几天一直在为我工作。祝你好运！

Answer 4

就我而言，我通过将joblib点子包从0.13.2升级到0.14.1来解决了这个问题。升级后错误消失。

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

4 个答案: