Come calcolare max_connections per PostgreSQL e default_pool_size per pgbouncer?

Esiste una regola o qualcosa che posso usare per calcolare un buon numero per max_connections, default_pool_sizee max_client_conn?

I valori predefiniti sono dispari. PostgreSQL è impostato su max_connections = 100 mentre pgbouncer è impostato su default_pool_size = 20. Default_pool_size non dovrebbe essere sempre superiore a max_connections? Altrimenti, che senso ha? Pensavo che pgbouncer fosse pensato per permetterci di gestire più connessioni riducendo il loro overhead (riutilizzando le connessioni di PostgreSQL). Non ho capito bene.

Sto cercando consigli simili a quelli trovati nel wiki di PostgreSQL , come "questo parametro dovrebbe essere ~ 50% della tua memoria".

Ricordo che c'era un foglio di calcolo per MySQL che ti avrebbe permesso di calcolare questo tipo di parametri. Sarebbe fantastico avere qualcosa del genere per PostgreSQL / pgbouncer.

Innanzitutto, leggi la nostra domanda canonica sulla pianificazione della capacità .
^{_{Il consiglio specifico che stai chiedendo è il consiglio di pianificazione della capacità e dovrai risolverlo da solo, per il tuo particolare ambiente.}}

Secondo, stai guardando questo male.
La quantità di memoria (o qualsiasi altra risorsa) di cui disponi non determina il numero di connessioni impostate, il numero di connessioni necessarie determina la necessità di acquistare un server robusto.
I requisiti delle risorse per connessione sono indicati nel manuale in modo molto dettagliato, così come discussi nel Wiki a cui si è collegati. Scopri di cosa ha bisogno il tuo ambiente (o fai un'ipotesi plausibile) e assicurati che l'hardware su cui eseguirai possa gestire ciò che stai per lanciare.

In particolare per quanto riguarda i limiti di connessione e le dimensioni del pool, è necessario disporre di connessioni "sufficienti" per soddisfare i requisiti dell'applicazione, su un singolo server o tramite un pool / bouncer.

"Abbastanza" è un numero relativo: un'applicazione che effettua (e riutilizza continuamente) una connessione richiede solo una connessione. Un'applicazione che stabilisce una connessione per ogni utente finale che accede richiede quante più connessioni DB quanti sono gli utenti.

I valori predefiniti per Postgres e pgbouncersono sensibili come valori predefiniti :

• 100 connessioni al database sono molte per la persona tipica che lancia Postgres in un ambiente.
  Probabilmente gli sviluppatori non avranno bisogno di più di 10. Chiunque altro ne saprà abbastanza per aumentare il numero.

• 20 connessioni pgbouncerper pool di DB significano che è possibile ottenere 4 pool che puntano su un server e non superare il limite di connessione Postgres predefinito.
  È possibile disporre di più risorse in pool nel pgbouncerpuntare a un database back-end e si desidera sempre alcune connessioni disponibili sui server back-end.

Se le impostazioni predefinite non sono adatte al proprio ambiente, è necessario modificarle.

Ricordare che le connessioni in pool non significano "collegare sempre ogni connessione al database disponibile".
Il punto di pgbouncercome hai notato è riutilizzare le connessioni. Il vantaggio in termini di efficienza qui non richiede il collegamento di tutte le connessioni disponibili, ma semplicemente il fatto di non disconnettere, riconnettere, rinegoziare SSL, riautenticare al database e rieseguire ogni volta le query di impostazione della connessione.

Si noti la definizione della documentazione didefault_pool_size

Quante connessioni al server consentire per coppia utente / database.

Pertanto, se la configurazione predefinita è una dimensione del pool di 20, su un totale di 100 connessioni, ciò implica che 5 coppie distinte utente / database dovranno massimizzare ciascuna la dimensione del pool prima di raggiungere il limite complessivo. Al contrario, se ad esempio stai usando pgbouncer per instradare a un singolo database tramite un singolo utente, il limite di connessione effettiva è 20, non 100, quindi devi impostare le dimensioni del pool per quel caso d'uso di conseguenza. YMMV.