Kann mir bitte jemand Klarheit über das Sidekiq Worker-Datenbank-Pooling geben?
Derzeit haben wir DISCOURSE_DB_POOL auf 15 gesetzt, wobei 2 Sidekiq-Worker jeweils eine Nebenläufigkeit von 10 haben. Nach dem Lesen der Sidekiq-Dokumentation scheint es, dass Sidekiq-Threads den DB-Pool gemeinsam nutzen. Daher gehe ich von maximal 15 * 2 = 30 DB-Verbindungen von Sidekiq-Workern aus. Trotz dieses Verständnisses beobachten wir jedoch Spitzen bei den DB-Verbindungen, die das erwartete Maximum von 30 überschreiten.
Ich fürchte, ich kenne die Details, wie das alles funktioniert, nicht auswendig.
Es könnte sich lohnen zu prüfen, ob Sie die UNICORN_SIDEKIQS-Umgebungsvariable angepasst haben. Diese gibt an, wie viele Sidekiq-Prozesse gestartet werden (von denen jeder viele Threads haben wird).
Was genau zeigt Ihr Diagramm an? Sind es “gleichzeitige Verbindungen”? Oder ist es “Anzahl der erstellten Verbindungen”? Wenn es letzteres ist, werden vielleicht einige Verbindungen sehr schnell erstellt und zerstört.
Und eine letzte Frage: Welches Problem versuchen Sie hier zu lösen? Verursacht die Anzahl der Verbindungen irgendein Problem?
Im Folgenden finden Sie die zugehörigen Konfigurationen, die wir haben:
DISCOURSE_DB_POOL: „15“
DISCOURSE_SIDEKIQ_WORKERS: „10“
UNICORN_SIDEKIQS: „2“
Das bedeutet, wir haben 2 Sidekiq-Prozesse mit jeweils 10 Threads.
Das Diagramm zeigt die aktuelle Anzahl der Client-Verbindungen.
Wir versuchen, die Größe des Connection Pools (RDS-Proxy vor PostgreSQL) korrekt zu konfigurieren. Dazu benötigen wir ein besseres Verständnis des Connection Poolings auf der Anwendungsseite. Warum beachtet die Anwendung die DISCOURSE_DB_POOL-Konfiguration nicht wie erwartet?
Wenn DISCOURSE_DB_POOL wie erwartet funktioniert, warum sehen wir dann solche großen Spitzen bei den DB-Verbindungen? Diese Spitzen scheinen mit den Ausführungen des geplanten Jobs „PeriodicalUpdates“ übereinzustimmen.
Bitte lassen Sie mich wissen, wenn Sie weitere Fragen haben. Ich schätze Ihre Hilfe, um das Rätsel zu lösen.
