Problem: Extrem langsame Sidekiq-Verarbeitung nach großen Importen auf Multisite-Instance

Unterstützung
1

Wir betreiben mehrere Discourse-Sites mit Multisite unter einer einzigen App. Kürzlich haben wir eine Charge großer Benutzerimporte durchgeführt (Hunderttausende von Benutzern über 6 Sites). Nach den Importen verarbeitet Sidekiq Hintergrundjobs sehr langsam. Das Sidekiq-Dashboard zeigt einen riesigen Rückstand an, und Jobs werden viel langsamer abgearbeitet als erwartet.

Umgebungsdetails:

  • Die VM wurde auf 16 CPUs / 16 GB RAM aufgerüstet.
  • In der Sidekiq-Oberfläche sehen wir jedoch nur 5 Threads, und es scheint, als würde nur ein kleiner Teil der Ressourcen genutzt.
  • Die Hauptimportwarteschlange („nursingjobs“ als Multisite-Mutter) verarbeitet Jobs für alle untergeordneten Sites, aber der Jobdurchsatz ist sehr gering.
  • Servermetriken: CPU manchmal bei 80–90 %, Speicher bei etwa 6,7/7,2 GB.

Wir möchten:

  • Die Sidekiq/Hintergrundjob-Verarbeitung beschleunigen, um große Rückstände nach dem Import zu beseitigen.
  • Sicherstellen, dass Discourse alle verfügbaren Ressourcen (CPU/RAM) nutzt.
  • Verstehen, ob es Thread-/Prozesslimits gibt, die angepasst werden müssen.

Fragen:

  1. Was ist der beste Weg, Sidekiq/Discourse für hohen Durchsatz nach dem Import zu konfigurieren?
  2. Was sind die empfohlenen Einstellungen für UNICORN_SIDEKIQS und DISCOURSE_SIDEKIQ_WORKERS auf großen Mehrkernsystemen?
  3. Gibt es Postgres- oder andere app.yml-Einstellungen, die wir anpassen sollten, um DB-Poolfehler zu vermeiden, wenn die Sidekiq-Concurrency erhöht wird?
  4. Gibt es Best Practices, um riesige Sidekiq-Rückstände nach Importen schnell und sicher zu beseitigen?

Das Bild zeigt ein Sidekick.io-Dashboard mit Prozessanzahlen, fehlgeschlagenen Instanzen, Latenz und drei Warteschlangenaufgaben mit jeweils Optionen zum Löschen. (Beschriftet von AI)
Das Bild zeigt ein Sidekick.io-Dashboard mit Prozessanzahlen, fehlgeschlagenen Instanzen, Latenz und drei Warteschlangenaufgaben mit jeweils Optionen zum Löschen. (Beschriftet von AI)1920×590 139 KB

Sidekiq-Statistiken/Screenshots sind verfügbar, falls hilfreich!

3

Die Antwort auf all diese Fragen ist mehr oder weniger, die Erhöhung von DISCOURSE_SIDEKIQ_WORKERS.

Ich würde das auf vielleicht 32 hochsetzen, da du weißt, dass du viel freie CPU-Ressourcen hast. Wenn nach einer Weile noch viel CPU verfügbar ist, kannst du es gerne noch weiter erhöhen.

Für den normalen Betrieb könntest du es wahrscheinlich wieder auf etwa 8 oder 12 reduzieren.

Stelle sicher, dass du genug max_connections für Postgres hast. Du hast es wahrscheinlich schon erhöht, da du Multisite betreibst, aber behalte es im Auge.

2 „Gefällt mir“
4

Danke @supermathie, es funktioniert jetzt.
Ich habe die Konfiguration wie folgt aktualisiert:

  UNICORN_WORKERS: 8
  UNICORN_SIDEKIQS: 7
  DISCOURSE_SIDEKIQ_WORKERS: 10
  DISCOURSE_DB_POOL: 20

Und die CPU erhöht auf:

8 vCPU
16 GB Arbeitsspeicher
1 „Gefällt mir“