Introduction
PgBouncer est un outil essentiel pour quiconque utilise PostgreSQL à grande échelle, mais il a une limitation majeure : il est monothread. Dans un monde où les serveurs multi-cœurs sont la norme, tirer parti de toute la puissance de traitement disponible est crucial. Pourtant, sur un serveur avec 16 vCPU, un seul cœur est utilisé pour le pooling des connexions, laissant les autres quasiment inutilisés.
Chez ClickHouse Managed Postgres, nous avons trouvé un moyen de contourner cette limitation, permettant ainsi de multiplier par quatre le débit de PgBouncer. Cet article va te montrer comment nous avons réalisé cette prouesse.
Le Problème du Monothreading
PgBouncer, par sa conception, utilise un seul fil d'exécution par processus. Cela signifie qu'un seul cœur est utilisé, même si plusieurs sont disponibles. Sur un serveur typique, cela entraîne un goulot d'étranglement bien avant que PostgreSQL ne soit à sa capacité maximale.
Sur un serveur avec 16 vCPU, seule une fraction des ressources est exploitée, limitant ainsi le nombre de connexions simultanées et le débit global. La question est : comment pouvons-nous utiliser efficacement tous ces cœurs inutilisés ?
La Solution d'Architecture
La clé réside dans l'utilisation de plusieurs processus PgBouncer en parallèle. Chaque processus est lié au même port grâce à l'option so_reuseport, permettant au noyau de répartir les connexions entrantes entre les différents processus. Cela signifie que, même si PgBouncer est monothread, chaque processus peut être affecté à un cœur différent, maximisant ainsi l'utilisation des ressources disponibles.
Les Défis de l'Annulation de Requêtes
L'un des principaux défis de cette approche est la gestion des annulations de requêtes. Dans PostgreSQL, une demande d'annulation arrive sur une nouvelle connexion avec une clé d'annulation, séparée de la connexion exécutant la requête. Avec so_reuseport, le noyau peut affecter cette nouvelle connexion à un autre processus que celui gérant la session initiale. Cela signifie que l'annulation pourrait ne jamais atteindre la requête cible.
Pour résoudre ce problème, nous avons mis en place un mécanisme qui assure que les annulations sont traitées correctement, en s'assurant que chaque processus peut communiquer efficacement pour retransmettre les demandes d'annulation au bon endroit.
Résultats et Performances
Grâce à cette architecture, nous avons pu multiplier par quatre le débit de PgBouncer. En répartissant les connexions sur plusieurs processus et en utilisant la pleine puissance de traitement des serveurs modernes, nous avons optimisé l'efficacité de notre gestion des connexions.
Non seulement cela améliore la performance, mais cela réduit également les temps de réponse pour les utilisateurs finaux, améliorant ainsi l'expérience globale.
Conclusion
Avec cette solution, ClickHouse Managed Postgres a démontré qu'il est possible de contourner les limitations inhérentes de PgBouncer pour en tirer un maximum d'efficacité. Si tu cherches à améliorer la performance de ta base de données PostgreSQL, envisage d'adopter une approche similaire.
Discutons de ton projet en 15 minutes.