Actuellement, je déploie mon application Flask sur un serveur Ubuntu (AWS). Quand j'essaye de démarrer le serveur uwsgi et de regarder avec journalctl les logs, je remarque une sorte d'avertissement / erreur.
Puis-je l'ignorer? Je ne sais pas comment le résoudre ni d'où il vient. Coincé là-dessus pendant 2 jours en ce moment. Qui peut m'aider?
Erreur:
*** 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)
4 Réponses :
Vous tentez de générer des sous-processus depuis l'intérieur de votre application (ou depuis une bibliothèque que vous utilisez). Selon cela, un co-processus supplémentaire est également engendré - le traqueur de sémaphore, chargé de renvoyer au système tous les sémaphores nommés créés par vos sous-processus. C'est une tâche importante, car si le sémaphore nommé est divulgué (non supprimé), la ressource système associée est occupée jusqu'au prochain redémarrage.
Le système dispose d'un nombre limité de ces ressources, car elles se trouvent dans la mémoire partagée. Vous pouvez ignorer cela si vous êtes sûr que le nombre de sémaphores nommés utilisés par votre application n'est pas significatif.
Notez que chaque type de verrou défini dans le module multitraitement est un sémaphore nommé sous le capot. De plus, chaque instance de multiprocessing.Queue, Barier, etc. instancie ses propres verrous.
Si, par exemple, vous engendrez de nombreux processus (workers) et que chacun d'entre eux instancie multiprocessing.Lock ou multiprocessing.RLock, le nombre de sémaphores nommés divulgués (non supprimés) peut être significatif, < strong> épuiser rapidement la limite , ce qui fait manquer de ressources à votre application ou à d'autres.
Voici un lien vers une explication de ces problèmes: https://docs.python.org/3/library/multiprocessing.html?highlight=semaphore%20tracker#contexts-and-start-methods
Pouvez-vous me donner un indicateur sur la façon de résoudre ce problème? Comment m'assurer que les sémaphores sont supprimés?
Hé, j'ai été aux prises avec le même problème, et bien que je ne sache pas comment empêcher l'avertissement de sémaphore spécifique d'apparaître, changer certaines de mes options uWSGI a aidé à améliorer le problème.
Mon .ini Le fichier de configuration est ci-dessous:
[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
Les ajouts que j'ai faits sont les options "harakiri" et "max-request". L'option harakiri signifie que si une demande prend plus de 30 secondes, le travailleur se recyclera, l'option max request signifie qu'après trois demandes, le travailleur se recyclera. Cela semble fonctionner, donc ma théorie est que même si les sémaphores peuvent ne pas être suivis, ils sont liés d'une manière ou d'une autre au travailleur, et leur recyclage améliore régulièrement les performances.
Il s'agit d'un "combat stupide" d'un fuite de mémoire et j'aurais aimé avoir une solution plus élégante, mais cela a fonctionné pour moi ces derniers jours. Bonne chance!
Je reçois toujours l'avertissement lorsque j'utilise cette configuration et que je redémarre mon service.
Comme je l'ai noté, cela ne supprime pas l'avertissement, mais cela devrait améliorer les performances de votre application.
Dans mon cas, cette erreur était due à l'utilisation de uWSGI 2.0.17.1 avec Flask 1.0.2 et scikit-learn 0.20.0.
En interne, scikit-learn importe joblib qui, au moment de l'importation, essaie de générer un processus de suivi de sémaphore (sklearn / externals / joblib / _multiprocessing_helpers.py).
Le processus de suivi de sémaphore est généré en générant une commande avec le nom de l'exécutable actuel et en ajoutant "-c 'à partir de multiprocessing.semaphore_tracker import main; main (fd)" .
Le nom de l'exécutable actuel devrait être «python» mais ce n'est pas le cas lors de l'utilisation de uWSGI. La commande résultante est "/ usr / local / bin / uwsgi -c 'de multiprocessing.semaphore_tracker import main; main (fd)" qui échoue et renvoie le message d'erreur ci-dessus.
Une solution de contournement, comme documenté ici , consiste à définir la variable d'environnement JOBLIB_MULTIPROCESSING = 0.
Notez que la seule conséquence de ceci, dans ma situation, était de générer un processus uWSGI défunt qui a finalement été nettoyé.
AFAIK la seule conséquence est qu'il engendrera un processus uWSGI qui deviendra directement caduc et sera récolté presque immédiatement.
Dans mon cas, j'ai résolu le problème en mettant à jour le package joblib pip de 0.13.2 vers 0.14.1 . L'erreur disparaît après la mise à jour.
Je me demandais si vous aviez jamais réussi à trouver une solution à cela, cela tue les performances de mon application et jusqu'à présent, je suis vide.
Je ne sais toujours pas comment résoudre ce problème. Je suis confus que je trouve très peu d'informations à ce sujet. Veuillez me faire savoir si vous avez trouvé quelque chose.