uwsgi - 无法从 multiprocessing.semaphore_tracker 加载配置答案

【问题标题】：uswgi - Unable to load configuration from from multiprocessing.semaphore_trackeruwsgi - 无法从 multiprocessing.semaphore_tracker 加载配置
【发布时间】：2019-05-31 05:00:02
【问题描述】：

目前我正在将我的 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)

【问题讨论】：

我想知道您是否能够找到解决此问题的方法，它正在扼杀我的应用程序的性能，到目前为止我还是一无所有。
我仍然不知道如何解决这个问题。我很困惑，我发现关于它的信息很少。如果您发现了什么，请告诉我。

标签： python ubuntu nginx flask uwsgi

【解决方案1】：

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

【讨论】：

【解决方案2】：

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

在内部，scikit-learn 导入 joblib，它在导入时尝试生成信号量跟踪进程 (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 进程，该进程最终被清除。

【讨论】：

AFAIK 唯一的后果是它会产生一个 uWSGI 进程，该进程将直接失效并几乎立即被回收。

【解决方案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 秒，worker 将自行回收，max request 选项意味着在三个请求后，worker 将自行回收。它似乎正在工作，所以我的理论是，虽然信号量可能未被跟踪，但它们以某种方式与工作人员联系在一起，并且定期回收它们可以提高性能。

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

【讨论】：

当我使用此配置并重新启动我的服务时，我仍然收到警告。
正如我所指出的，它并没有消除警告，但它应该可以提高应用程序的性能。

【解决方案4】：

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

系统拥有数量有限的这些资源，因为它们位于共享内存中。如果您确定您的应用使用的命名信号量并不重要，则可以忽略这一点。

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

例如，如果您产生许多进程（worker）并且每个进程都在实例化 multiprocessing.Lock 或 multiprocessing.RLock，则泄漏（未删除）命名信号量的数量可能很大，快速耗尽限制，导致您的应用或其他应用耗尽资源。

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

【讨论】：

你能告诉我如何解决它吗？如何确保删除信号量？