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.
Entschuldigung für mein Verschwinden und vielen Dank für die Antworten.
Ich glaube, dass das Hauptproblem für die Langsamkeit von Redis darin bestand, dass THP immer noch aktiviert war (obwohl ich dachte, es sei deaktiviert gewesen):
Für das Abstürzen von PG war die Hauptlösung für mich, dies zu app.yml hinzuzufügen:
docker_args:
- "--shm-size=34g"
Wobei der Wert auf db_shared_buffers + 2GB gesetzt ist, wobei db_shared_buffers 25 % des gesamten RAMs des Host-Rechners beträgt.
Ich habe mir Ihren Beitragsverlauf angesehen und sehe in Sehr langsames Sidekiq-Problem … riesige Mengen ungelesener Benutzerbenachrichtigungen, dass Sie einen Server mit 32 Kernen und 128 GB hatten, mit einer sehr großen und aktiven Benutzerbasis. In diesem Zusammenhang verstehe ich, warum 34G keine so große Zahl ist! Zum besseren Verständnis wäre es jedoch hilfreich (und interessant) zu wissen, wie groß Ihr Setup ist – möglicherweise hier oder sogar in Ihrer Biografie? (vielleicht tägliche und monatlich aktive Benutzer, Größe der Datenbank-Backups, Serverkonfiguration in Bezug auf RAM, Swap, Festplatte, CPUs.) Vielleicht sogar ein Thread, in dem wir einfach unsere Statistiken teilen – große und kleine.
