Ich bekomme ständig diese Meldung in den Protokollen – mit Werten zwischen ca. 100.000 und ca. 1,35 Mio. – aber die Werte nahe 100.000 scheinen recht häufig zu sein:
Ihre Redis-Netzwerkverbindung ist extrem schlecht. Die letzten RTT-Messwerte waren [97069, 103986, 98459, 100762, 381617], idealerweise sollten diese < 1000 sein. Stellen Sie sicher, dass Redis in derselben AZ oder demselben Rechenzentrum wie Sidekiq läuft. Wenn diese Werte nahe 100.000 liegen, bedeutet dies, dass Ihr Sidekiq-Prozess möglicherweise CPU-gesättigt ist; reduzieren Sie Ihre Nebenläufigkeit und/oder siehe https://github.com/mperham/sidekiq/discussions/5039
Das deutet darauf hin, dass Redis vielleicht nicht genug CPU nutzen kann? Auf dem Server selbst scheint es aber genügend Spielraum für CPU und RAM zu geben.
Außerdem: Sidekiq verbraucht zu viel Speicher (verwendet: 3570,19M) für 'www.example.com', startet neu
Dies verwendet die All-in-One-App.yml mit Discourse Stable 3.3.2.
Aus der app.yml:
UNICORN_SIDEKIQS: 9
DISCOURSE_SIDEKIQ_WORKERS: 5
Ich habe diese Konfiguration auch auf dem Host hinzugefügt:
Um dies zu verfolgen, habe ich dasselbe Problem mit Jobs::PostAlert:
Mit diesen Jobs, die oft bis zu 15 Minuten dauern, wenn 4 Sidekiqs mit 5 (Standard) Threads verwendet werden, mit aktuellen Tests. Es scheint, dass die Geschwindigkeit der Jobs pro Sekunde für Sidekiq hauptsächlich davon abhängt, wie viele dieser Jobs gleichzeitig ausgeführt werden und wie viele Threads für die anderen Jobs frei sind.
Die Erhöhung von Sidekiqs auf 6 oder höher (5 Threads) erhöht die Geschwindigkeit der Warteschlangenbereinigung, aber Postgres stürzt regelmäßig ab (ich vermute, wegen zu vieler gleichzeitig ausgeführter Jobs::PostAlert-Jobs).
Dies ist auf Stable 3.3.2. Die Änderungen und Korrekturen aus dem verlinkten Thread scheinen bereits in 3.3.2 implementiert zu sein, wenn ich mich nicht irre.
