uwsgi Arbeiter stecken: Warum

Question

Ich verwende uwsgi Version 2.0.13.1 mit folgenden Konfiguration:

bin/uwsgi -M -p 5 -C -A 4 -m -b 8192 -s :3031 --wsgi-file bin/django.wsgi --pidfile var/run/uwsgi.pid --touch-reload=var/run/reload-uwsgi.touch --max-requests=1000 --reload-on-rss=450 --py-tracebacker var/run/pytrace --auto-procname --stats 127.0.0.1:3040 --threads 40 --reload-mercy 600 --listen 200 

(absolute Pfadnamen schneiden)

Als ich uwsgitop laufen, alle 5 Arbeitnehmer beschäftigt erscheinen . Wenn ich versuche, den Stack-Trace für jeden Worker/Thread mit dem py-tracebacker zu bekommen, bekomme ich keine Antwort. Die Prozesse hängen einfach.

Wie könnte ich recherchieren, was genau die Ursache dafür ist, dass uwsgi-Prozesse hängen bleiben?

Wie könnte ich diese Situation verhindern?

Ich kenne die Harakiri-Parameter, aber ich bin mir nicht sicher, ob der Prozess getötet wird, wenn es andere aktive Threads hat.

PD: "Reload Gnade" ist auf einen sehr hohen Wert gesetzt, vermeiden Sie das Töten von Arbeitern mit noch aktiven Threads (scheint ein Fehler zu sein). Wir haben einige Web-Anfragen, die noch lange dauern (die auf dem Weg sind, in Jobs umgewandelt zu werden).

Vielen Dank im Voraus.

Answer 1

Obwohl ich bereits einen Kommentar hinzugefügt habe, hier eine längere Beschreibung.

Warnung: Das Problem trat nur auf, wenn mehr als ein Arbeitsprozess UND mehr als ein Thread (-p - Threads) verwendet.

Kurzversion: In Python 2.7.x sind einige Module nicht 100% Thread-sicher während des Imports (Protokollierung, impliziter Import von Codecs). Versuchen Sie, alle problematischen Module in die wwsgi-Datei zu importieren, die an uwsgi übergeben wurde (d. H. Vor uwsgi-Gabeln).

Lange Version: In https://github.com/unbit/uwsgi/issues/1599 habe ich das Problem analysiert und festgestellt, dass es mit python bug with the logging module verwandt sein könnte. Das Problem kann gelöst werden, indem alle kritischen Module vor uwsgi forks importiert und initialisiert werden, die nach der Ausführung des wwsgi-Skripts für uwsgi ausgeführt werden.

Ich löste schließlich mein Problem beim Importieren der Django-Einstellungen.ROOT_URLCONF direkt oder indirekt aus der Wsgi-Datei. Dies hat auch die Vorteile, dass der Speicherverbrauch (weil die Code-Basis, die zwischen den Arbeitern geteilt wird, viel größer ist) und die Initialisierungszeit pro Arbeiter reduziert wird.