Latence base de données sous charge : connexions et pooling
- Une base qui rame sous charge, c'est rarement la puissance.
- Le vrai facteur : le nombre de connexions ouvertes.
- Chaque connexion coûte de la mémoire ; passé un seuil, la base s'écroule.
- Un pool borne ce nombre et la latence redescend.
Questions fréquentes
Le pooling peut-il masquer une vraie fuite de connexions dans mon code ?
Il la cache un temps, c'est exactement le risque. Si votre application oublie de rendre des connexions au pool (un bloc try sans finally, une exception qui court-circuite la libération), le pool finit par les épuiser toutes et vos requêtes se mettent à attendre indéfiniment. Surveillez le taux d'occupation du pool et le nombre de connexions empruntées qui ne reviennent pas : un pool toujours plein n'est pas un pool bien dimensionné, c'est souvent une fuite.
PgBouncer suffit-il, ou faut-il aussi de la haute disponibilité dessus ?
Posé seul devant la base, PgBouncer devient un point de défaillance unique : s'il tombe, plus rien ne passe. Pour de la production sérieuse, on le double et on place un mécanisme de bascule devant (une IP virtuelle gérée par keepalived, ou le routage de votre orchestrateur). Le process est léger, le doubler ne coûte presque rien en ressources, mais c'est une étape qu'on oublie facilement tant que la première panne n'est pas arrivée.