uswgi - Невозможно загрузить конфигурацию из multiprocessing.semaphore_tracker

Question

В настоящее время я развертываю свое приложение Flask на сервере Ubuntu (AWS). Когда я пытаюсь запустить сервер uwsgi и просматривать журнал в журналах, я замечаю своего рода предупреждение / ошибку.

Могу ли я игнорировать это? Я не знаю, как ее решить или откуда она взялась. Застрял в этом на 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

Привет, я боролся с той же проблемой, и хотя я не знаю, как на самом деле предотвратить появление предупреждения о конкретном семафоре, изменение некоторых параметров 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 означает, что если запрос занимает более 30 секунд, рабочий перезапустит сам себя, параметр max request означает, что после трех запросов рабочий перезапустит сам себя. Кажется, это работает, поэтому моя теория состоит в том, что, хотя семафоры не отслеживаются, они каким-то образом привязаны к рабочему, и их регулярная переработка регулярно повышает производительность.

Это «глупая борьба» с утечкой памяти, и мне бы хотелось, чтобы у меня было более элегантное решение, но оно работало для меня последние несколько дней. Удачи!

Answer 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 'из multiprocessing.semaphore_tracker import main; main (fd)" .

Ожидается, что имя текущего исполняемого файла будет python, но это не так при использовании uWSGI. В результате получается команда "/ usr / local / bin / uwsgi -c 'из multiprocessing.semaphore_tracker import main; main (fd)" , которая выдает ошибку и выдает указанное выше сообщение об ошибке.

Обходной путь, как задокументировано здесь , - установить переменную среды JOBLIB_MULTIPROCESSING = 0.

Обратите внимание, что единственное последствие этого в моей ситуации - генерирование несуществующего процесса uWSGI, который в конечном итоге был очищен.

Answer 3

Вы пытаетесь порождать подпроцесс (ы) изнутри вашего приложения (или из используемой вами библиотеки). В соответствии с этим также создается дополнительный совместный процесс - средство отслеживания семафоров, отвечающее за возврат в систему всех именованных семафоров, созданных вашими подпроцессами. Это довольно важная задача, потому что, если указанный семафор просочился (не удален), связанный системный ресурс будет занят до следующей перезагрузки.

Система имеет ограниченное количество этих ресурсов, поскольку они находятся в общей памяти. Вы можете игнорировать это, если уверены, что количество именованных семафоров, используемых вашим приложением, не является значительным.

Обратите внимание, что каждый тип блокировки, определенный в многопроцессорном модуле, является именованным семафором под капотом. Более того, каждый экземпляр многопроцессорной обработки. Queue, Barier и т. Д. Создают свои собственные блокировки.

Если, например, вы порождаете много процессов (рабочие), и каждый из них создает экземпляры multiprocessing.Lock или multiprocessing.RLock, количество пропущенных (не удаленных) именованных семафоров может быть значительным, быстрое исчерпание лимита , что приводит к исчерпанию ресурсов вашего приложения или других пользователей.

Вот ссылка на объяснение этих вопросов: https://docs.python.org/3/library/multiprocessing.html?highlight=semaphore%20tracker#contexts-and-start-methods