<p>gunicorn 19.x verursacht Probleme mit django-1.7.1 und gevent</p>

Nur eine Frage zuerst: Hilft es, die Preload-Option herauszunehmen?
Ich glaube, ich erinnere mich, dass ein anderes ähnliches Problem gemeldet wurde.
Wenn das Ändern dieser Option hilft, müssen wir etwas daran geändert haben, wie Django-Anwendungen geladen werden, und es wird für uns einfacher sein, sie aufzuspüren.

Ich _glaube_, wir importieren die Django-Wsgi-Anwendung in den Masterprozess, der zumindest auf Django 1.7 alle Django-Modelle beim Import initialisiert.

Hallo @tilgovi , danke für deine Zeit. Ich kann nicht bestätigen, dass ich mit preload_app = False gunicorn-19.1.1 und django-1.7.1 .

Haben Sie eine Ahnung, was Gunicorn Cloud in den Versionen 19.x anders macht?

Ich habe jetzt ein zweites Problem. Ich verwende Raven[1] in meiner Django-App. Und gemäß den Raven-Dokumenten ist es bei Verwendung einer WSGU-Middleware[1] möglich, Raven als WSGI-Objekt zu verwenden (umhüllt die ursprüngliche Django-WSGI-App) und bei Verwendung von gunicorn (als externer Befehl, nicht als run_gunicorn django-Befehl) müssen wir gunicorn[2] einen Hook hinzufügen. Wenn dieser Hook aktiviert ist, bootet gunicorn nur, wenn preload_app = True , aber dann funktioniert gevent nicht. Wenn ich preload_app = True mit aktiviertem Hook verwende, bootet gunicorn nicht einmal, was mir und ImportError sagt, dass es mein "DJANGO_SETTINGS_MODULE" nicht importieren kann.

Rabe ist 4.2.3

Ich werde vorerst auf gunicorn 18.x zurückkommen, da es mit beiden Konfigurationen funktioniert (gevent und raven als WSGI-Middleware).
Soll ich dazu ein weiteres Issue eröffnen?

[1] http://raven.readthedocs.org/en/latest/config/django.html#wsgi -middleware
[2] http://raven.readthedocs.org/en/latest/config/django.html#gunicorn

@daltonmatos die Art und Weise, wie Datenbanken in Django 1.7.1 eingerichtet werden, hat sich wahrscheinlich geändert, ist anscheinend nicht threadsicher. Ich bin mir zu diesem Zeitpunkt nicht sicher, was ich tun soll.

Noch eine Sache, die ich heute erst herausgefunden habe,
Session-Handling in django 1.7 mit gunicorn 19.3.0 läuft innerhalb von Sekunden ab.

Musste auf 18 umstellen, damit es funktioniert.

Zu Ihrer Information.

Dies scheint das gleiche Problem wie https://github.com/benoitc/gunicorn/issues/879 zu sein , das geschlossen, aber nicht behoben wurde. Es macht Gunicorn 19.x. unbrauchbar mit Django. Aber vielleicht nur für den Gevent-Arbeiter? Ich habe nicht für andere Worker-Typen getestet.

@tilgovi Ich frage mich, ob es nicht an der Änderung in der Umgebung liegt. in 19.x setzen wir wsgi.multithread auf true wo es in 18.x false war:

https://github.com/benoitc/gunicorn/blob/master/gunicorn/workers/ggevent.py#L99

Diese Änderung kann in django anders gehandhabt werden. Und ein Greenlet ist nicht wirklich ein Thread. Die Gedanken? Zumindest könnten wir vielleicht versuchen, es rückgängig zu machen und zu prüfen, ob es das Problem löst. Haben wir einen Test oder einen reproduzierbaren Weg für dieses Problem?

Oh, ich wette, das ist das Problem. Gutes Gedächtnis, @benoitc.

Ich weiß immer noch nicht warum. Wie ich damals sagte, um die Änderung zu begründen, kann ich mir nicht vorstellen, dass dadurch etwas kaputt geht, weil das Framework nur mehr Vorkehrungen für den Datenaustausch treffen würde. Offensichtlich kann ich falsch liegen.

Ich habe den Branch fix/927 gedrückt, um zu überprüfen, ob der obige Fix funktioniert. Bitte testen!

Ich kann diesen Fehler immer noch mit fix/927 mit django 1.8.1 (und 1.7.1) und gevent 1.0.1 reproduzieren

Das beruhigt mich, auch wenn wir die Ursache noch nicht kennen.

Also habe ich versucht, die Beispielanwendung zu verwenden und das Problem mit der folgenden Befehlszeile nicht reproduziert:

gunicorn --env DJANGO_SETTINGS_MODULE=testing.settings -k gevent -w3 wsgi:application

Kann mir jemand ein reproduzierbares Beispiel liefern?

Ich kann dieses Problem immer noch reproduzieren, indem ich Gunicorn wie folgt aufrufe:

    gunicorn --env DJANGO_SETTINGS_MODULE=settings -w 3 --max-requests=1000 -b 0.0.0.0:8000 -k gevent --config ogs/gunicorn.py  --pythonpath ogs wsgi:application

Benötigen Sie relevante Details?

@brockhaywood sollte project.settings , aber ja, ich muss eine Möglichkeit haben, es zu reproduzieren, haben Sie einen minimalen Code zum Teilen.

Wenn man sich die obige Spur ansieht, könnte es auch das Affenflicken sein. Vielleicht sollten Threads nicht mit Affen gepatcht werden. Kannst du folgenden Patch ausprobieren?

--- a/gunicorn/workers/ggevent.py
+++ b/gunicorn/workers/ggevent.py
@@ -60,9 +60,9 @@ class GeventWorker(AsyncWorker):

         # if the new version is used make sure to patch subprocess
         if gevent.version_info[0] == 0:
-            monkey.patch_all()
+            monkey.patch_all(thread=False)
         else:
-            monkey.patch_all(subprocess=True)
+            monkey.patch_all(subprocess=True, thread=False)

         # monkey patch sendfile to make it none blocking
         patch_sendfile()

Die Verwendung des obigen Patches mit dem folgenden wsgi führt nicht mehr zu dem angegebenen Fehler:

import os

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "settings")

from gevent import monkey
monkey.patch_all(thread=False)

from django.core.wsgi import get_wsgi_application
application = get_wsgi_application()

from django.core.cache.backends.memcached import BaseMemcachedCache
BaseMemcachedCache.close = lambda self, **kwargs: None

Ich sehe jetzt einen anderen und neuen Fehler, habe aber keine Ahnung, ob er damit zusammenhängt:

ProgrammingError: close cannot be used while an asynchronous query is underway

Dies geschieht, 1 von 10/15 Anfragen führt eine Zählung für ein Modell durch. Ich vermute, dass dies ein Fehler in meiner Anwendung ist, der jetzt aufgedeckt wurde.

@brockhaywood cool! Übrigens, was ist deine Version von Gevent? Für Ihren neuesten Fehler scheint es in der Tat nicht mit Gunicorn zu tun zu haben.

Ja, gute Nachrichten! Auf Version 1.0.1 von gevent.

@tilgovi, also frage ich mich, ob wir Gunicorn nicht patchen sollten, um das Thread-Affen-Patching zu entfernen. Vielleicht sollten wir auch wsgi.multithread auf False ? Die Gedanken?

@benoitc Ich kann den neuen Fehler, auf den ich oben verwiesen habe, mit einer sehr einfachen Django-Anwendung reproduzieren, die nur eine Ansicht hat und eine einfache Modellabfrage durchführt und zählt, wenn ich mehrere gleichzeitige Anforderungen ausführe.

Haben Sie Vorschläge, welche Komponente der wahrscheinlichste Täter ist? Ist das wahrscheinlich ein Gevent-Problem oder psycogreen?

Eher Psychogrün. Verwenden Sie einen solchen Haken, um es einzurichten?

def def_post_fork(server, worker):
    from psycogreen.gevent import psyco_gevent
    psyco_gevent.make_psycopg_green()
    worker.log.info("Made Psycopg Green")

Oh, ich benutze tatsächlich

def post_fork(server, worker):    
    from psycogreen.gevent import patch_psycopg
    patch_psycopg()

Ich werde deinen Vorschlag ausprobieren.

Ihr Code ist genauer, wenn ich den Code von psycogreen lese:

https://bitbucket.org/dvarrazzo/psycogreen/src/115d0627da1ac9ff48c0cb9287257cd35868cdf9/psycogreen/gevent.py?at=master#cl -17

Ok, ich werde versuchen, ein Ticket mit psycogreen zu öffnen

können Sie versuchen, den Hook post_worker_init anstelle von post_fork ?

Tritt bei mir immer noch beim Patchen von psycogreen in post_worker_init auf.

Ich habe auch ein Ticket bei psycogreen eingereicht:
https://bitbucket.org/dvarrazzo/psycogreen/issue/2/databaseerror-used-with-asynchronous-query

@brockhaywood OK:/ https://bitbucket.org/dvarrazzo/psycogreen-hg/issue/1/databaseerror-execute-used-with . Ich bin mir aber nicht sicher, ob es dir helfen könnte.

Ich habe mir das angeschaut und es scheint das gleiche Problem zu sein, aber ich habe leider keine Lösung gefunden.

@brockhaywood können Sie ein einfaches

Hier das einfache Projekt, das ich zum Reproduzieren verwende:
https://github.com/brockhaywood/gunicorn_gevent_issue

Danke!

Am Sonntag, 17. Mai 2015 um 22:34 Uhr brockhaywood [email protected]
schrieb:

Hier das einfache Projekt, das ich zum Reproduzieren verwende:
https://github.com/brockhaywood/gunicorn_gevent_issue

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/benoitc/gunicorn/issues/927#issuecomment -102852497.

@benoitc irgendwelche Gedanken dazu?

@brockhaywood Entschuldigung, ich hatte keine Zeit, es zu testen. Da ich morgen in einem Flug eingeschlossen bin, werde ich sowieso :)

Vielen Dank
Am 26. Mai 2015 um 13:17 Uhr schrieb "Benoit Chesneau" [email protected] :

@brockhaywood https://github.com/brockhaywood Entschuldigung, ich hatte keine Zeit
um es zu testen. Da ich morgen in einem Flug eingeschlossen bin, werde ich sowieso :)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/benoitc/gunicorn/issues/927#issuecomment -105652947.

Hatte gerade das gleiche DatabaseWrapper-Problem, als ich diesen Thread sah.

Ich kann bestätigen, dass das Entfernen der Option preload_app aus meiner gunicorn-Konfigurationsdatei das Problem behebt. Ich benutze:

• Django==1.7.7
• gevent==1.0.2
• Gunicorn==19.3.0
• psycopg2==2.5.2
• Psychogrün==1.0
• Gunicorn von PgBouncer gewickelt

(Springen Sie ein, da wir die gleichen Probleme wie in diesem Thread beschrieben haben)

Es sieht so aus, als ob diese Probleme durch die Fehlerbehebung für Problem Nr. 478 verursacht werden (nicht den Master patchen).

Dadurch, dass der Master nicht mit Affen gepatcht wird, erzeugt das App-Preload im Grunde eine Diskrepanz, wenn Sie gevent-Worker verwenden. Jeder App-Code, der als Teil des Preloads ausgeführt wird, wird in einer Umgebung ausgeführt, die nicht mit Monkey-Patches versehen ist. Jeder App-Code, der im Worker ausgeführt wird, wird in einer Umgebung mit Affenpatches ausgeführt.

Für uns, einfach die Methode setup in die gevent Worker-Klasse zurückzusetzen, wie sie in 18.x definiert ist, so dass der Master Affen-gepatcht wird und er vor dem Vorladen der App Affen-gepatcht wird, alles behoben unsere Probleme. Dies beinhaltet den DatabaseWrapper Bug sowie ein weiteres Problem, bei dem Gevent-Worker hängen blieben und eine Zeitüberschreitung hatten. Es waren keine weiteren Änderungen erforderlich (wir müssen beispielsweise das Affen-Patching threads nicht deaktivieren).

Ich wäre immer noch sehr zögerlich, den Master-Prozess zu patchen, aber wenn Sie dies tun möchten, können Sie möglicherweise die Server-Hooks verwenden, anstatt Gunicorn selbst zu patchen. Wenn Sie das können, würde ich mich über jede Möglichkeit freuen, dies an einem Ort zu dokumentieren, der besser ist als hier.

Ich denke, der kurzfristige Plan für uns ist, eine (interne) Gunicorn-Gabel mit diesem Patch zu erstellen.

Ich werde untersuchen, wie man einen Affen-Patch-Schritt in unseren wsgi-Code verschiebt, aber dies scheint immer noch etwas zu sein, das innerhalb des Gunicorn-Codes erfolgen sollte (sogar als konfigurierbare Option). Das Patchen in vorgeladenem App-Code wirkt sich auf die eine oder andere Weise auf den Master aus, und der springende Punkt wäre, den Affen-Patch-Zustand der Worker mit dem Master synchron zu halten. Das Anwenden des Master-Affen-Patches im App-Code bedeutet, dass App-Entwickler, die auf dieses Verhalten angewiesen sind, immer alle Änderungen nachholen, die gunicorn daran vornimmt, wann / wie es den Arbeiter patcht.

Wenn es funktioniert, früh zu patchen, sollte dies vielleicht als Änderung betrachtet werden.

Ich kann mich nicht erinnern, ob das jemals der Fall war und ob das Probleme verursacht hat, aber es ist immer schwierig, mit Affen zu flicken.

Unsere eigene Produktion gunicorn Anwendung erfordert Vorbelastung und so erfordert auch Affen Patchen im Master (verwenden wir Pyramide / Paste von pserve Skript die App und laden gunicorn aus einer INI - Datei zu starten, haben wir einen Wrapper um es zu sein sicher, dass Monkey-Patching so schnell wie möglich erfolgt).

Ich bin ein aktueller gevent-Maintainer. Ich freue mich, alle Probleme in gevent zu prüfen, die erforderlich sind, damit dieses Szenario besser funktioniert. Wir gehen davon aus, dass 1.1 bald veröffentlicht wird und es wäre großartig, wenn dies eine unterstützte Option wäre.

Ich habe versucht, die gleiche Monkey-Patch-Logik oben in unserer wsgi-Implementierung anzuwenden, und wir sahen das Problem DatabaseWrapper . Ich bin mir jedoch nicht ganz sicher, warum - wenn man sich den wsgi-Aufruf in arbiter.py ansieht , passiert dies ein paar Zeilen nach dem Punkt, an dem GeventWorker.setup aufgerufen wird (als Nebeneffekt der worker_class-Zuweisung . Wenn ich das lese) richtig codieren.

Ich werde nachfassen, wenn ich ein Heureka habe oder Glück in Bezug auf den App-Code habe, aber bisher ist für uns das frühere Patchen des Gunicorn-Mastercodes die einzige Lösung, die alle unsere Probleme löst.

@jamadden vielen Dank.

@jzupko Es ist normalerweise wichtig, dass das Patchen vor allen möglicherweise betroffenen Importen erfolgt. Aus diesem Grund habe ich vorgeschlagen, dies in einem Server-Hook zu tun, indem Sie beispielsweise eine post_fork Funktion in eine gunicorn.conf.py Datei einfügen. Mir ist jedoch gerade aufgefallen, dass das Vorladen der Anwendung vor einem der Server-Hooks stattfindet und es nicht klar ist, wo man das tun würde.

@ benoitc haben wir einen Mechanismus für die arbeiterspezifische Konfiguration?

Ich füge dies dem Meilenstein von Release 20 hinzu und schlage vor, dass wir vielleicht in Betracht ziehen, den Master zu patchen, wenn dies möglich ist, ohne Probleme wie # 478 erneut einzuführen.

@tilgovi Sie haben die Methode setup des Workers, die meiner Meinung nach dafür verwendet werden kann.

Hat jemand eine vorübergehende Lösung dafür, bis 20.0 herauskommt? Oder ist die einzige Lösung, zwischen der Deaktivierung von preload_app oder einem Downgrade auf 18.0 zu wählen?

@fletom vorübergehende Lösung für? Hast du den neuesten Master probiert? Hat es bei dir funktioniert?

@benoitc Ich meine einen Fix für den Fehler "DatabaseWrapper-Objekte".

Der aktuelle Gunicorn Master funktioniert bei mir überhaupt nicht. Am regulären 19.6.0 bekomme ich das (normal):

[2017-01-05 15:46:32 -0500] [3222] [INFO] Starting gunicorn 19.6.0
[2017-01-05 15:46:32 -0500] [3222] [INFO] Listening at: http://127.0.0.1:8000 (3222)
[2017-01-05 15:46:32 -0500] [3222] [INFO] Using worker: gevent
[2017-01-05 15:46:32 -0500] [3226] [INFO] Booting worker with pid: 3226
[2017-01-05 15:46:32 -0500] [3227] [INFO] Booting worker with pid: 3227
[2017-01-05 15:46:32 -0500] [3228] [INFO] Booting worker with pid: 3228
[2017-01-05 15:46:32 -0500] [3229] [INFO] Booting worker with pid: 3229

Und auf dem neuesten Master mit der zu 100% genau gleichen Konfiguration erhalte ich dies, und soweit ich das beurteilen kann, lauscht nichts an einem Port:

[2017-01-05 15:47:19 -0500] [3308] [INFO] Starting gunicorn 19.6.0
[2017-01-05 15:47:19 -0500] [3308] [INFO] Listening at:  (3308)
[2017-01-05 15:47:19 -0500] [3308] [INFO] Using worker: gevent
[2017-01-05 15:47:19 -0500] [3312] [INFO] Booting worker with pid: 3312
[2017-01-05 15:47:19 -0500] [3313] [INFO] Booting worker with pid: 3313
[2017-01-05 15:47:19 -0500] [3314] [INFO] Booting worker with pid: 3314
[2017-01-05 15:47:19 -0500] [3315] [INFO] Booting worker with pid: 3315

Scheint verwanzt zu sein?

@fletom wie startet man Gunicorn?

@benoitc In diesem Fall ist es gunicorn -c gunicorn_conf.py <appname>.wsgi .

Mein gunicorn_conf.py ist:

workers = 4

worker_class = 'gevent'

preload_app = False

Ich stolpere über dieses Problem mit gunicorn==18.0 . In der gunicorn_conf.py habe ich worker_class = 'gevent' , preload_app = True und benutzerdefinierte pre_fork , on_starting und on_reload Funktionen.

Das Einfügen dieser Zeilen über die Datei gunicorn_conf.py scheint das Problem für mich zu lösen:

import gevent.monkey
gevent.monkey.patch_thread()

Aktualisieren:
Ich hatte diese Zeilen in meiner gunicorn.conf. Sie loszuwerden löste das Problem ohne Monkey-Patching.

import django
django.setup()

Wegen ihnen initiierte Django die Verbindung vor Gunicorns Affenflicken.

@gukoff vorgeschlagene Korrektur hat bei mir nicht funktioniert, ich erhalte immer noch den gleichen Fehler 😞

Ich werde dies schließen und eine Diskussion mit dem Mailinglisten-Label über den R20-Meilenstein für das Affen-Patching des Schiedsrichters in Gevent eröffnen. Wenn Sie Probleme im Zusammenhang mit dieser Diskussion haben und denken, dass es sich um einen Fehler in Gunicorn handeln könnte, öffnen Sie bitte ein Problem. Sie können dies nummerisch erwähnen oder auf Kommentare verlinken, wenn es hilft, Kontext hinzuzufügen, aber an dieser Stelle ist dies ein altes Ticket mit parallelen Gesprächen über mehrere Versionen von Gunicorn und verschiedene Symptome.