Qualcuno può fornire chiarimenti sul pooling del database dei worker Sidekiq?
Attualmente, abbiamo impostato DISCOURSE_DB_POOL su 15, con 2 worker Sidekiq ciascuno con una concorrenza di 10. Dopo aver letto la documentazione di Sidekiq, sembra che i thread Sidekiq condividano il pool del database, quindi prevedo un massimo di 15 * 2 = 30 connessioni al database dai worker Sidekiq. Tuttavia, nonostante questa comprensione, stiamo osservando picchi nelle connessioni al database che superano il massimo previsto di 30.
Temo di non conoscere i dettagli su come tutto questo funzioni all’istante.
Potrebbe valere la pena verificare se hai personalizzato l’ambiente UNICORN_SIDEKIQS. Quello indica quanti processi sidekiq vengono avviati (ognuno dei quali avrà molti thread).
Cosa mostra esattamente il tuo grafico? Sono ‘connessioni concorrenti’? O è ‘numero di connessioni create’? Se è quest’ultimo, forse alcune connessioni vengono create e distrutte molto rapidamente.
E un’ultima domanda: quale problema stai cercando di risolvere qui? C’è qualche problema causato dal numero di connessioni?
Di seguito sono riportate le configurazioni correlate che abbiamo:
DISCOURSE_DB_POOL: “15”
DISCOURSE_SIDEKIQ_WORKERS: “10”
UNICORN_SIDEKIQS: “2”
Ciò significa che abbiamo 2 processi Sidekiq, ciascuno con 10 thread.
Il grafico mostra il numero attuale di connessioni client.
Stiamo cercando di configurare correttamente la dimensione del pool di connessioni (RDS proxy davanti a PostgreSQL). Per fare ciò, abbiamo bisogno di una migliore comprensione del connection pooling lato applicazione. Perché l’applicazione non rispetta la configurazione DISCOURSE_DB_POOL come previsto?
Se DISCOURSE_DB_POOL funziona come previsto, perché vediamo picchi così grandi nelle connessioni DB? Questi picchi sembrano essere allineati con le esecuzioni pianificate del job PeriodicalUpdates.
Per favore, fammi sapere se hai altre domande. Apprezzo l’aiuto per svelare il mistero.
