502-Fehler bei nginx

Hallo,

ich habe gerade ./launcher rebuild app ausgeführt, ohne dass Fehler aufgetreten sind. Wenn ich jedoch versuche, die Website zu öffnen, erhalte ich einen 502-Fehler.

Im Nginx-Fehlerprotokoll (shared/standalone/log/var-log/nginx/error.log) steht:

2020/08/12 05:47:43 [error] 653#653: *7 connect() failed (111: Connection refused) while connecting to upstream, client: [...], server: _, request: "GET / HTTP/2.0", upstream: "http://127.0.0.1:3000/", host: "[...]"

Ich habe alle Themen durchsucht, die ich über Discourse und Nginx-502-Fehler finden konnte, aber nichts gefunden oder verstanden, was in meinem Fall Sinn ergibt.

Dies könnte relevant sein, ausgeführt im Container:

# netstat -plant
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name    
tcp        0      0 0.0.0.0:6379            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      644/nginx: master p 
tcp        0      0 0.0.0.0:5432            0.0.0.0:*               LISTEN      -                   
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN      644/nginx: master p 
tcp6       0      0 :::6379                 :::*                    LISTEN      -                   
tcp6       0      0 :::5432                 :::*                    LISTEN      -

Sollte auf Port 3000 etwas laufen?

Könntest du mich bitte anleiten, wo ich nach weiteren Informationen suchen kann, um dieses Problem zu debuggen?

Pura vida :slight_smile:

Es wird zunächst eine 502 angezeigt, da die Dienste im Container gestartet werden. Sie sollte innerhalb von 30 Sekunden verschwinden. Falls dies nicht der Fall ist, ist es möglich, dass die CPU Ihres Servers extrem belastet ist und dies zu Verlangsamungen führt.

3 „Gefällt mir“

Danke @itsbhanusharma.

Ich habe ./launcher restart app ausgeführt und die Auslastung mit top überwacht; sie liegt deutlich unter 10 %.

Ich denke, die CPU sollte ausreichen, um die Last zu bewältigen:

$ cat /proc/cpuinfo  | grep 'name' | uniq
model name      : Intel(R) Xeon(R) CPU E5-1650 v3 @ 3.50GHz
$ cat /proc/cpuinfo  | grep process | wc -l
4

Gibt es eine bessere Möglichkeit, den Start des Containers zu debuggen?
Weitere Ideen?

1 „Gefällt mir“

Welche Plugins sind installiert? Läuft dieser Server auf einer SSD?

Ich habe das Repository gerade geklont und die Setup-Befehle ausgeführt, also hat es wahrscheinlich nur die Standard-Plugins? Ich bin mir nicht sicher, wo ich das überprüfen kann, aber ich bin mir sicher, dass ich keine hinzugefügt habe.

Der Server ist kein SSD.

Hallo @elopio

Könntest du deine ‘yml’-Datei ohne sensible Informationen posten?

Klar, hier ist es:

Discourse erfordert eine SSD; normale mechanische Festplatten liefern nicht genügend IOPS.

Ist das die Ursache für den 502-Fehler? Oder sollte die Website ohne SSD zwar funktionieren, aber sehr langsam sein?

Die Verwendung einer herkömmlichen Festplatte im Vergleich zu einer SSD sollte keinen 502-Fehler verursachen. Das ist, wie Ihre Frage an @elopio zeigt, nicht wirklich plausibel.

Hier ist ein kleiner Beitrag, der hilfreich sein könnte:

Das Beste, was man tun kann, ist meiner Meinung nach, einige Terminals zu öffnen und auf Ihren Rails- und nginx-Logdateien (einschließlich der Fehler- und Zugriffsprotokolle) tail -f auszuführen. Versuchen Sie dann, auf die Seite zuzugreifen, und achten Sie darauf, dass Sie beim Auftreten des 502-Fehlers die Ausgabe der Logdateien im Auge behalten.

Wissen Sie, wo sich diese Logdateien befinden und wie man tail -f-Befehle in den Terminals darauf ausführt?


Hinweis: Sie haben früher gefragt:

Rails läuft innerhalb des Docker-Containers auf Port 3000, und dieser Port ist nicht nach außen exponiert. Deshalb sehen Sie Port 3000 außerhalb des Containers nicht, wenn Sie netstat außerhalb des Containers ausführen.

HTH

Aus Erfahrung kann eine langsame E/A-Operation definitiv zu Timeouts und einem 502-Fehler führen.

IOPS auf SSD-Niveau sind eine zwingende Voraussetzung.

Wooo, als ich mir die Rails-Logs angesehen habe, stellte ich fest, dass das Unicorn-Log riesig war und über einige Berechtigungsfehler klagte. Ich habe rm -rf tmp/cache/bootsnap-compile-cache/ gelöscht, und jetzt sehe ich den Glückwunsch-Bildschirm!!!

Danke, Freunde. Ich werde das noch ein wenig ausprobieren, bevor ich entscheide, es auf einem SSD-Server neu zu erstellen.

4 „Gefällt mir“

Gerne geschehen, @elopio.

Schön, dass du das Problem in den Logs gefunden und es gelöst hast. Gut gemacht.

Ich wünsche dir weiterhin viel Erfolg und eine reibungslose Fahrt!

1 „Gefällt mir“

Ok, das funktioniert großartig. Ich möchte zeigen, was wir tun:

https://bunqueer.jaquerespeis.org/

Es ist die Migration des Costa-ricanischen Hackerspaces von Telegram zu Discourse :slight_smile: Wir haben noch sooo viele Dinge zu erledigen, aber dieses Mal bin ich sicher, dass wir den Chat definitiv loswerden können. Vielen Dank an das Discourse-Team!

2 „Gefällt mir“

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.