Seit dem heutigen Neuaufbau erleben wir eine hohe Anzahl an Serverfehlern. Es scheint sich um ein nginx-Verbindungsproblem zu handeln; in nginx/error.log sehe ich manchmal eine Flut von 768 worker_connections are not enough-Meldungen wie dieser hier:
2021/06/02 10:42:21 [alert] 1143#1143: *28468 1768 worker_connections are not enough while connecting to upstream, client: (IP entfernt), server: _, request: "POST /message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/8fc08436f86f47479cf0dad3deb5c4dc/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/convert-multiple-objects-to-single-mesh-with-vertex-grouping/489173/2"
Habt ihr eine Idee, wie wir das beheben können? Wir haben ausreichend CPU- und Speicherressourcen verfügbar – könnten wir die Anzahl der „worker connections
Update: Ich habe vorübergehend die Anzahl der Worker-Verbindungen erhöht, aber ich erhalte weiterhin diese Fehler (allerdings seltener und bei einer höheren Anzahl von Workern). Ich bin sehr neugierig, ob sich kürzlich etwas geändert hat, das dies verursachen könnte, oder wie ich das Problem besser eingrenzen kann.
## Beliebige benutzerdefinierte Befehle, die nach dem Build ausgeführt werden sollen
run:
- exec: echo "Beginn der benutzerdefinierten Befehle"
- replace:
filename: "/etc/nginx/letsencrypt.conf"
from: "worker_connections 768"
to: "worker_connections 1768"
Interessant, dass dies nach einem Rebuild passiert ist. Haben Sie kürzlich Massenaktionen durchgeführt? Ich würde die Sidekiq-Logs prüfen und sehen, ob dort ebenfalls eine große Anzahl von Jobs vorhanden ist.
Ich habe kürzlich einige Massenaktionen durchgeführt, als wir auf die Thumbnail-Vorschau TC umgestellt haben, aber in meiner Sidekiq-Warteschlange ist nichts zu sehen. Das kann ich definitiv ausschließen.
Wir haben die nginx-Version vor zwei Tagen aktualisiert, also sollten wir sie im Auge behalten. Hast du auf deiner Website mehr als 500 gleichzeitige Besucher?
Außerdem liegt deine gesamte Website hinter Cloudflare, daher können die Verhältnisse aufgrund davon anders sein.
Ich habe keine Ahnung – vielleicht? Hast du eine Idee, wie ich das überprüfen kann?
Richtig. Aber ich habe jegliche Beschleunigung deaktiviert und nutze es im Grunde nur, um Bilder und Avatare zu cachen. Bis heute war das noch nie ein Problem.
Haha, normalerweise nutzen Leute Google Analytics oder Ähnliches, um solche Informationen zu erhalten. Das Discourse-Dashboard bietet tägliche Seitenaufrufe und Benutzerbesuche, die ebenfalls dafür verwendet werden können.
Das stimmt nicht, deine gesamte Website wird über Cloudflare ausgeliefert:
Das mag jedoch völlig irrelevant sein, da dein nginx sich über Upstream-Verbindungen beschwert, nicht über Downstream-Verbindungen. Das bedeutet, dass die Verbindung zwischen nginx ⟷ unicorn erschöpft ist.
Da wir für jeden Besucher eine offene Verbindung aufgrund von message_bus (Live-Updates-Dienst) offenhalten, ist dies gewissermaßen zu erwarten, wenn deine Website einigermaßen beliebt ist.
Das Erhöhen von worker_processes und worker_connections ist sicher und klingt in deinem Fall sinnvoll. Standardmäßig setzen wir worker_processes auf die Anzahl deiner CPU-Kerne. Wie viele CPU-Kerne hast du?
Stimmt Wir haben das vor langer Zeit abgeschaltet. Wir haben etwa 250.000 Seitenaufrufe pro Tag (einschließlich Bots), also scheinen 500 nicht ungewöhnlich. Die Benutzerbesuche erfassen doch nur angemeldete Besuche, oder?
Richtig – wir müssen unsere Anfragen zwar über CF leiten, lassen sie aber nicht unseren JavaScript-Code usw. manipulieren.
Wir haben 12 Kerne und 64 GB RAM. Die typische Auslastung liegt bei etwa 2, und wir nutzen 50 % unseres RAMs.
Die Formel für Verbindungen lautet worker_processes * worker_connections, was 12 * 768 ergeben sollte, also (klick klack) 9216. Aber deine Logs zeigen 1768…
Versuche das hier in deiner app.yml:
## Beliebige benutzerdefinierte Befehle, die nach dem Build ausgeführt werden sollen
run:
- exec: echo "Beginn der benutzerdefinierten Befehle"
- replace:
filename: "/etc/nginx/nginx.conf"
from: "worker_connections 768"
to: "worker_connections 2000"
- replace:
filename: "/etc/nginx/nginx.conf"
from: "worker_processes auto"
to: "worker_processes 10"
Beachte, dass dein Block in Beitrag 2 die falsche Datei bearbeitet!
Ich habe den falschen Code eingefügt – ich habe zuerst die letsencrypt-Vorlage ausprobiert, aber am Ende die nginx.conf auf 1768 Worker-Verbindungen geändert.
Ich werde deine Werte ausprobieren – ich melde mich zurück, um zu berichten, wie es läuft.
2021/06/02 17:40:03 [alert] 2102#2102: *262491 2000 worker_connections reichen nicht aus, während eine Verbindung zum Upstream aufgebaut wird, client: <ip entfernt>, server: _, request: "POST /message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t HTTP/1.1", upstream: "http://127.0.0.1:3000/message-bus/0e453fae0c604c29a876e6ede05b7341/poll?dlp=t", host: "blenderartists.org", referrer: "https://blenderartists.org/t/weight-paint-not-painting/551282"
Genau. Wir haben außerdem die Standardeinstellung in demselben Patch auf 4k erhöht, sodass Administratoren sorgfältig prüfen sollten, ob sie diese weiterhin erhöhen müssen.
Wir haben das vor langer Zeit abgeschaltet. Wir haben etwa 250.000 Seitenaufrufe pro Tag (einschließlich Bots), also scheinen 500 nicht ungewöhnlich. Die Benutzerbesuche erfassen doch nur angemeldete Besuche, oder?
Ich habe den falschen Code eingefügt – ich habe zuerst die letsencrypt-Vorlage ausprobiert, aber am Ende die nginx.conf auf 1768 Worker-Verbindungen geändert.