bad gateway 502 wegen zu vielen Daten?

[Pitwheazle]

In meiner Rechentrainer-App können die Lehrkräfte die Arbeit ihrer Lerngruppen einsehen. Zwischenzeitlich habe ich eine Funktion eingebaut, mit der man den Zeitraum eingrenzen kann, in der Aufgaben gerechnet wurde. Das funktioniert auch wunderbar - eigentlich. Ein Kollege hat seine Kids dazu gebracht sehr fleißig zu üben. Die Gruppe hat bisher über 120 000 Aufgaben gerechnet und jede Aufgabe hat einen Datensatz. Wenn der Kollege, oder auch ich, versuche einen bestimmten Zeitraum einzugeben, rödelt der Filter eine ganze Weile rum und gibt dann den Fehler "bad gateway 502" zurück. Wenn ich das mit anderen Gruppen ausprobiere, kommt recht schnell eine Antwort und wenn ich die Datenbank runterlade und die Suche lokal auf meinem Computer auszuführen, klappt es auch. Habt ihr eine Idee?

[noisefloor]

Hallo,

... rödelt der Filter eine ganze Weile rum und gibt dann den Fehler "bad gateway 502" zurück.

Inhaltlich so nicht richtig - das ist für die Fehlersuche aber wichtig. Ich denke, dass du sagen willst ist, dass du die Daten auf der Webseite abfragst, dann länger nichts passiert und dann dein Browser den 502 anzeigt?

Ein ziemlich gute Erklärung, wie es zu einem 502 Bad Gateway kommen kann, gibt es bei MDN: https://developer.mozilla.org/en-US/doc ... Status/502. Das Setup bei Uberspace ist ja, dass ein Reverse-Proxy vor dem Applikationsserver sitzt. Und da bzw. dazwischen liegt irgendwo der Fehler. Deswegen bekommst du den Fehler auch nicht lokal, weil du da wahrscheinlich den Entwicklungsserver von Django benutzt und kein Setup aus Reverse-Proxy und WSGI-Applikationsserver? Jedenfalls solltest du in erster Instanz in den Logs des Server bei Uberspace nachschauen, da solltest du eigentlich was finden. Kannst die Zeilen mit den Fehlermeldung(en) auch gerne hier posten. Vorher natürlich doppelt checken, ob keine sensiblen Daten drin sind (sollte normalerweise nicht der Fall sein).

120.000 Datensätze sind nicht viel. Also nicht in Bezug auf die Datenmenge. Und wenn die Abfrage doch zu lang dauern sollte, dann solltest du normalerweise einen 504 Timeout bekommen.

Gruß, noisefloor

[Sirius3]

Ich vermute mal, dass Django schon eine halbe Antwort schickt und dann in einen Timeout läuft, aber ohne die genaue Konfiguration zu kennen, ist das natürlich nur raten. Wenn die Datenbank zu langsam antwortet, ist das ein Zeichen dafür, dass Indices nicht richtig gesetzt sind. Da solltest Du mal Deine Datenbankabfragen debuggen. Eigentlich jedes professionelle Datenbanksystem bietet da entsprechende Statistiken an.

[Pitwheazle]

Vielne Dank, dass ihr euch wieder mal meiner Probleme annehmt.
Ich habe irgendwann es hinbekommen, dass Uberspace mir eine Email sendet wenn ein Fehler auftritt. Das passiert auch öfters mal, wenn in meinem Code etwas nicht stimmt (oder genauer irgendeine Eingabe so von mir nicht berücksichtig wurde) - in diesem Fall habe ich aber keine Nachricht erhalten. In den Logs von uber finde ich zunächst ein "supervisord.log" - ich finde da keine Hinweise auf Fehler. Dann habe ich mich kundig gemacht. Es gibt noch die Möglichkeit ein "webserver/access.log" zu aktivieren. Das habe ich getan, den Fehler ausgelöst und das Log angschaut - auch da stehen nur die Zugriffsdaten drin und keine Fehlermeldung. Ich glaube ich deaktiviere das Log wieder, da ich da keinen tieferen Nutzen drin sehe. Wo kann ich noch suchen?

weil du da wahrscheinlich den Entwicklungsserver von Django benutzt und kein Setup aus Reverse-Proxy und WSGI-Applikationsserver?

... vermutlich. Aber ehrlich gesagt, habe ich auch da wieder mal keine Ahnung.

Ich vermute mal, dass Django schon eine halbe Antwort schickt und dann in einen Timeout läuft, aber ohne die genaue Konfiguration zu kennen, ist das natürlich nur raten.

Welche Info kann ich dazu geben?

Da solltest Du mal Deine Datenbankabfragen debuggen. Eigentlich jedes professionelle Datenbanksystem bietet da entsprechende Statistiken an.

Da bräuchte ich auch einen Hinweis, wie ich da drangehe.

[geraldfo]

Vielleicht gibt’s neben dem access.log noch ein error.log

[Pitwheazle]

Es gibt noch einen "apache_error log" - der ist leer und ein "php_error log":

Code: Alles auswählen

[16-Apr-2025 11:30:01] NOTICE: configuration file /opt/uberspace/etc/rt/php-fpm.conf test is successful

[16-Apr-2025 11:30:03] NOTICE: using inherited socket fd=3, "/run/php-fpm-rt.sock"
[16-Apr-2025 11:30:03] NOTICE: fpm is running, pid 13143
[16-Apr-2025 11:30:03] NOTICE: ready to handle connections
[16-Apr-2025 11:30:03] NOTICE: systemd monitor interval set to 10000ms

Nachtrag:
Ich könnte ja mal "debug = True" in den settings einstellen.
Nö, bringt keine Änderung - es ist ja wohl, wenn ich euch richtig verstehe, auch kein Fehler in meinem Code.

[noisefloor]

Nö, bringt keine Änderung - es ist ja wohl, wenn ich euch richtig verstehe, auch kein Fehler in meinem Code.

So sieht's aus. Bzw. vielleicht indirekt, weil der Code zu langsam oder ineffizient oder so ist, aber es ist ziemlich sicher kein Fehler im Code an sich, der dazu führt, dass Python einen Fehler wirft.

Was vielleicht noch bei der Fehlersuche hilft:

* https://manual.uberspace.de/web-backends/
* https://manual.uberspace.de/web-logs/

Für Django gibt es AFAIK auch diverse Logging Tools - habe ich selber aber noch nie benutzt.

Gruß, noisefloor

[Sirius3]

Du benutzt doch mysql, da gibt es logs: https://dev.mysql.com/doc/refman/9.3/en ... y-log.html

[sparrow]

War das nicht sqllite?

[Pitwheazle]

* https://manual.uberspace.de/web-backends/
* https://manual.uberspace.de/web-logs/
Für Django gibt es AFAIK auch diverse Logging Tools - habe ich selber aber noch nie benutzt.

Das erste habe ich abgearbeitet und das Ergebnis beschrieben.
Beim zweiten weiß ich nicht so recht, ob mir das hilft.

War das nicht sqllite?

Jawohl

Ich vermute ja immer noch, dass der Filter zulange braucht um die Daten rauszusuchen - oder käme dann ein anderer Fehler? Bei den Lerngruppen mit weniger Daten funktioniert die Abfrage ja.

[Sirius3]

Was, Dein Produktivsystem arbeitet immer noch auf sqlite?
Ok, dann schalte mal das Logging von Django ein, und schaue, welche Query besonders langsam ist: https://docs.djangoproject.com/en/5.2/r ... b-backends
oder ob es davon ziemlich viele gibt.

[Pitwheazle]

Ich entnehme deiner Antwort, dass ich dann doch mal auf mysql wechseln sollte? (Die Anleitung dazu im uberspace Handbuch hat mich zunächst mal überfordert - aber wenn ihr es hilfreich findet, mache ich mich da mal dran).
Auch das Logging sieht schon mal nicht so einfach aus. Wenn ich das richtig sehe, muss ich das auf meiner lokalen Installation einsetzen?

[Sirius3]

Ja, das solltest Du lokal bei Dir machen. Denn bei Dir lokal gibt es ja keinen Timeout, da kannst Du das in Ruhe alles untersuchen.

[snafu]

Und den Support von Uberspace könntest du hierzu auch kontaktieren, sofern noch nicht geschehen.

[nezzcarth]

Ich entnehme deiner Antwort, dass ich dann doch mal auf mysql wechseln sollte?

Das empfohlene Datenbanksystem für Django ist eigentlich PostgreSQL. Falls MySQL/MariaDB bei deinem Provider einfacher ist oder dir Postgres zu kompliziert ist, geht das auch; die Unterschiede sind in Bezug auf die Django-Unterstützung in den letzten Version weniger geworden.

[sparrow]

Noch der Hinweis, weil das hier ein bisschen untergeht: Das Problem scheint kein Timeout zu sein.
Wenn ein Request ewig läuft, sollte das kein Problem sein. Und wenn es einen Timeout gibt, dann ist das nicht 502.

502 deutet auf ein Problem zwischen Webserver und Backend-Applikation hin.
Also läuft da ein nginx? Spricht der mit einem gunicorn? Oder vielleicht "nur" mit dem Entwicklungsserver. Könnten es gleichzeitige Requests sein, die zu dem Problem führen und das fällt hier nur auf, weil jetzt ein langer Requests läuft und dann ein weiterer kommt.

Das nur als Hinweis, bevor da jetzt stundenlang an einer Query optimiert wird.

[Sirius3]

Wenn eine Anfrage mit ein paar Tausend Datensätzen ewig dauert, dann gibt es zumindest damit auch ein Problem.
Da tatsächlich nginx eingesetzt wird, deutet ein 502 auf einen plötzlichen Abbrucht zu Django hin. Gleichzeitige Requests sollten da kein Problem sein. Ich habe eine ähnliches Setup mit Hundert gleichzeitigen Nutzern ohne jemals auf 502 gestoßen zu sein.
Meine wahrscheinlichste Vermutung ist nun Out-of-Memory. Könnte sein, dass die Datensätze alle auf einmal im Speicher landet und dass das dann zu viel wird. `query.all()` sollte man nie benutzen.

[noisefloor]

Hallo,

wenn ich die Doku von Uberspace richtig verstehe, ist Apache der Standardserver bei Uberspace und der agiert auch als Reverse Proxy. AFAIR hat Pitwheazel sich an diese Doku beim Einrichten der Applikation auf Uberspace gehalten : https://lab.uberspace.de/guide_django/ Da läuft dann Gunicorn als WSGI Applikationsserver.

Gruß, noisefloor

[Sirius3]

@noisefloor: nein, das Konstrukt ist etwas komplizierter. Anfragen werden zuerst von nginx empfangen, um dann entweder an gunicorn für dynamische Seiten oder apache für statische Seiten weiterzuleiten.

[einfachTobi]

Dann könnte doch tatsächlich ein Timeout von Gunicorn der Grund sein.