PostgreSQL en production, les 5 erreurs de configuration qui dégradent vos performances

Votre base de données PostgreSQL tourne depuis un moment en production.

Les équipes n'ont pas touché au code, l'infrastructure n'a pas bougé et pourtant les performances se dégradent. Les requêtes prennent plus de temps, des timeouts apparaissent, la charge monte sans explication évidente.

Dans la plupart des situations de ce type que nous rencontrons, le problème ne vient ni du code applicatif ni du matériel. Il vient de la configuration de PostgreSQL lui-même, qui n'a jamais été ajusté pour correspondre à l'usage réel de la base en production.

PostgreSQL est livré avec des paramètres par défaut volontairement prudents, conçus pour fonctionner sur n'importe quel serveur sans risque. C'est une qualité au moment de l'installation. C'est une limite dès que la charge réelle arrive. Et parce que la dégradation est souvent progressive, elle passe inaperçue jusqu'au moment où elle devient un problème difficile à ignorer.

Voici les cinq erreurs de configuration PostgreSQL que nous relevons le plus fréquemment lors de nos audits.

1. shared_buffers sous-dimensionné : un cache mémoire qui force des lectures disque inutiles

PostgreSQL dispose d'un cache interne qui lui permet de conserver en mémoire les données fréquemment lues, et d'éviter d'aller les chercher sur disque à chaque requête. Par défaut, ce cache est fixé à une valeur qui n'a aucun rapport avec la mémoire réellement disponible sur le serveur de production.

"Les requêtes qui devraient répondre en quelques millisecondes prennent plusieurs secondes. La charge I/O grimpe. Le symptôme ressemblant à beaucoup d'autres choses, on perd du temps à chercher ailleurs."

C'est l'un des premiers points que nous vérifions lors d'un audit de configuration.

2.  work_mem insuffisant : des opérations complexes qui débordent silencieusement sur le disque

Chaque opération de tri, de jointure ou de hachage a besoin d'un espace mémoire dédié pour s'exécuter. Quand cet espace est insuffisant, PostgreSQL déborde sur le disque pour finir le travail. Ce comportement est invisible dans les logs si on ne sait pas où chercher, mais il peut multiplier le temps d'exécution d'une requête par dix ou vingt.

"Une requête analytique tourne parfaitement en recette, sur un jeu de données réduit, puis devient problématique en production dès que le volume réel entre en jeu. Le code n'a pas changé."

Ce type de problème se détecte avec les bons outils d'analyse, et se corrige sans toucher au code applicatif.

3. Trop de connexions PostgreSQL : un réflexe qui aggrave souvent la situation

Quand une application commence à saturer les connexions disponibles, le réflexe est d'augmenter la limite. C'est souvent ce qui aggrave la situation.

Au-delà d'un certain seuil, chaque connexion supplémentaire consomme des ressources partagées et génère de la contention interne. Les performances globales se dégradent, même quand le serveur a encore de la mémoire disponible.

"C'est un des comportements les plus contre-intuitifs de PostgreSQL et l'un des plus coûteux quand il n'est pas anticipé."

La bonne réponse n'est généralement pas une modification du paramètre lui-même, mais une compréhension de l'évolution du nombre de connexions. Une solution possible est une gestion du pool de connexions avec PgBouncer.

4. Statistiques obsolètes : un optimiseur qui choisit les mauvais plans d'exécution

PostgreSQL s'appuie sur des statistiques internes (distribution des valeurs, cardinalité) pour choisir le plan d'exécution le plus efficace pour chaque requête. Si ces statistiques ne sont plus à jour, par exemple après un import massif ou un pic d'activité, l'optimiseur peut se tromper de plan et opter pour un scan complet là où un index aurait suffi.

"la durée d'éxécution des requêtes se met à augmenter pour prendre plusieurs secondes, sans modification de la partie applicative"

Un simple ANALYZE (manuel ou via un réglage plus agressif de l'autovacuum sur ce point précis) suffit à rétablir des plans cohérents, sans impact sur les données.

5. Autovacuum mal calibré : un nettoyage automatique qui ne suit pas la charge

PostgreSQL ne supprime pas immédiatement les données modifiées ou effacées. Il les conserve physiquement, marquées comme mortes et un processus de nettoyage est censé les supprimer complétement en arrière-plan. Quand ce processus n'est pas calibré pour la charge réelle, les tables grossissent progressivement sans que personne ne s'en aperçoive.

"Les performances se dégradent lentement, de façon diffuse, et la corrélation avec la configuration de nettoyage n'est pas évidente à établir sans expérience sur le sujet."

Sur des bases à fort volume de mises à jour, c'est presque systématiquement un point d'attention que nous relevons lors de nos interventions.

Les 5 erreurs en un coup d'œil

Erreur	Symptôme ressenti	Signal d'alerte
shared_buffers sous-dimensionné	Requêtes lentes, charge I/O élevée	Dégradation progressive depuis la mise en production
work_mem insuffisant	Requêtes analytiques très lentes	Écart de performance recette / production
Trop de connexions ouvertes	Timeouts, saturation applicative	Augmenter la limite n'améliore rien
Statistiques obsolètes	Requêtes rapides qui deviennent lentes	Plan d'exécution incohérent après un import ou un pic d'activité
Autovacuum mal calibré	Dégradation lente et diffuse	Tables qui grossissent sans raison apparente

Ce que ces erreurs ont en commun

Aucun de ces problèmes n'est lié à la qualité du code applicatif. Aucun ne nécessite de refonte architecturale majeure. Ils sont tous issus d'une configuration qui n'a pas évolué avec l'usage réel de la base de données PostgreSQL en production.

Ce qui rend leur diagnostic délicat, c'est qu'ils se ressemblent en surface, des lenteurs, une charge anormale, des timeouts intermittents. Sans une lecture précise des métriques internes de PostgreSQL, on peut facilement traiter le mauvais symptôme pendant longtemps.

Un audit de configuration permet d'établir un état des lieux objectif, de prioriser les actions selon leur impact réel, et d'intervenir sans risque sur un environnement de production.

Vous observez des signes de dégradation sur vos bases de données PostgreSQL en production ?

Nous sommes disponibles pour en discuter et évaluer ensemble ce qu'un audit pourrait apporter à votre contexte.

Chez Zen Conseil, nous prenons le temps de comprendre votre environnement avant de proposer quoi que ce soit : architecture, volumétrie, contraintes métier. L'objectif est de vous apporter une lecture précise de ce qui se passe réellement dans vos bases et des leviers concrets pour y remédier.

Echanger à propos de mes bases de données PostgreSQL !