Mehrere 503-Fehler nach Update

Installation
1

Wir haben gerade von 3.0.6 auf 3.1.2 aktualisiert und sehen viele 503-Fehler an hauptsächlich 3 Stellen:

  • Viele Avatare können nicht geladen werden
  • Bild-Uploads funktionieren nur manchmal
  • Sehen auch viele Fehler für topics/timings

Ich habe die Serverprotokolle überprüft, und die meisten 503er werden nicht einmal in production.log angezeigt, aber nginx ist voll davon. Da ich dachte, es könnte sich um eine Ratenbegrenzung von nginx handeln, habe ich versucht, die templates/web.ratelimited.template.yml nicht zu verwenden, aber es schien nicht zu helfen. Ich sehe immer noch eine hohe Anzahl von Anfragen, die mit 503 beantwortet werden, hauptsächlich user_avatars/show, und soweit ich das beurteilen kann, sieht production.log sie überhaupt nicht.

Nichts Ungewöhnliches in Sidekiq bemerkt. Allerdings gab es in /logs Fehler mit:

'hijack user_avatars show ' läuft immer noch nach 90 Sekunden auf db default, dieser Prozess muss möglicherweise neu gestartet werden!

aber das war ein paar Stunden her und ich habe die Instanz seitdem ein paar Mal neu erstellt und sie sind nicht wieder aufgetaucht.

Diese Instanz verwendet SSO, daher kommen die Avatare (URL) von dort. Wir verwenden S3 für Bilder.

Ich bin etwas ratlos, was die Ursache ist, und mir gehen die Ideen aus.

Irgendwelche Hinweise, wo/was ich untersuchen könnte?

2

Wie viel RAM hast du? Hast du den Server in letzter Zeit neu gestartet?

3

Der Server verfügt über 16 GB und lief vor dem Update monatelang problemlos.

Es handelt sich um eine AWS-Instanz, und diese wurde heute, kurz vor dem Update (Discourse-Daten befinden sich auf EBS-Volumes), gestartet, um einige nicht zusammenhängende Parameter zu ändern.

Der Netzwerkverkehr (rein und raus) hat nach dem Update erheblich zugenommen: Avatare scheinen einige Sekunden nach dem anfänglichen 503 zu funktionieren, daher vermute ich, dass beim ersten Anfordern ein Prozess läuft.

Ich bin jedoch ratlos, warum Bild-Uploads zufällig fehlschlagen und auch der Endpunkt topics/timings.

4

Ich bin mir nicht sicher, ob dies damit zusammenhängen könnte:

Könnte es sein, dass dieser Avatar-Hintergrund-Update-Prozess die 3500 PUT/s Ratenbegrenzung auf AWS trifft und dadurch normale Uploads fehlschlagen, während die Avatare aktualisiert werden? /cc @sam

1 „Gefällt mir“
5

Möglicherweise … es sollte sich aber klären. Hat es sich inzwischen geklärt?

1 „Gefällt mir“
6

Ja, teilweise.

Screenshot 2023-10-24 at 11.21.19
Screenshot 2023-10-24 at 11.21.191504×512 132 KB

Das Update wurde am Morgen des 21. durchgeführt. Der eingehende Netzwerkverkehr scheint sich jetzt zu normalisieren. Der ausgehende Verkehr ist immer noch höher als üblich, aber ich nehme an, das liegt daran, dass Avatare zwischengespeichert werden. Die Anzahl der 503-Fehler an user_avatars/show ist jetzt viel geringer. Ich vermute, dass sich diese im Laufe der Zeit langsam erledigen werden, wenn mehr Avatare verarbeitet werden.

Wir sehen jedoch immer noch viele 503-Fehler in den Protokollen für hauptsächlich zwei andere Endpunkte:

POST /topics/timings

Immer noch viele 503-Fehler an diesem Endpunkt und einige Benutzer berichten, dass besuchte Themen nicht als gelesen markiert werden. Ich habe keine Informationen darüber gefunden, da die Anfrage anscheinend überhaupt nicht in production.log protokolliert wird. Die /logs zeigen nichts Relevantes.

Wo könnte man diese 503er debuggen? Gibt es andere Protokolle, die mir nicht bekannt sind, oder gibt es eine Möglichkeit, die Protokolle detaillierter zu gestalten (auf einem Produktionssystem)?

POST /uploads.json?client_id=...

Alles, was ich in production.log für diese 503-Fehler finde, sieht ungefähr so aus:

Auszug aus production.log

Started POST “/uploads.json?client_id=X” for x.x.x.x at 2023-10-24 10:24:55 +0000
Processing by UploadsController#create as JSON
Parameters: {“upload_type”=>“composer”, “relativePath”=>“null”, “name”=>“Screenshot 2023-10-24 at 11.22.32.png”, “type”=>“image/png”, “sha1_checksum”=>“d1f11731320437724003c3840c5dcc5f934ba25a”, “file”=>#<ActionDispatch::Http::UploadedFile:0x00007f3c5e3c9898 @tempfile=#Tempfile:/tmp/RackMultipart20231024-1991-b30vit.png, @content_type=“image/png”, @original_filename=“Screenshot 2023-10-24 at 11.22.32.png”, @headers=“Content-Disposition: form-data; name="file"; filename="Screenshot 2023-10-24 at 11.22.32.png"\r\nContent-Type: image/png\r\n”>, “client_id”=>“X”}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 503 Service Unavailable in 10ms (Views: 0.4ms | ActiveRecord: 0.0ms | Allocations: 5007)

Unsere Benutzer berichten, dass sie es ein paar Mal versuchen, bis es funktioniert… Ich kann den Fehler mehr oder weniger konsistent reproduzieren, wenn ich versuche, eine (weitere) Datei hochzuladen, während bereits eine hochgeladen wird. Das Hochladen nacheinander scheint aus irgendeinem Grund weniger anfällig dafür zu sein.

# free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       3.8Gi       621Mi       1.1Gi        10Gi        10Gi

# lscpu --parse=core | egrep -v # | sort -u | wc -l
2

UNICORN_WORKERS: 4

db_shared_buffers: "1024MB"