⚠️ 11) Pièges courants
Objectif : identifier les erreurs de configuration les plus fréquentes et les bonnes pratiques pour les éviter.
Pièges Mémoire & Connexions
Absence de pooler, work_mem excessif, ou shared_buffers mal géré (HugePages).
Pièges Planner & Bloat
random_page_cost inadapté (HDD vs SSD) et un Autovacuum trop lent sur les grosses tables.
Pièges de Process
Modifier des paramètres "à l'aveugle" sans tests avant/après, et ne jamais tester les restaurations.
Piège: Trop de connexions sans pooler
Chaque connexion PostgreSQL est un processus (fork) consommant ~5-10MB de RAM *minimum*. 1000 connexions = 10Go de RAM juste pour les process, avant même de travailler. Cela cause un "context switching" CPU énorme et sature la mémoire.
Pratique: Utiliser un pooler (PgBouncer)
Mettre PgBouncer en mode
transaction. L'application ouvre 1000 connexions vers PgBouncer, mais PgBouncer n'ouvre que (par ex) 100 connexions réelles vers PostgreSQL (max_connections = 100). Efficacité maximale.Piège:
work_memtrop haut globalementRégler
work_mem = 1Godanspostgresql.confest dangereux. Si 100 connexions lancent un tri en même temps (ORDER BY,JOIN), cela consomme 100Go de RAM et provoque un OOM (Out Of Memory) killer.Pratique:
work_membas +SET LOCALGarder
work_membas (ex: 32-64MB) globalement. Pour des requêtes lourdes (BI, rapports), augmenterwork_mem*localement* pour cette session/requête viaSET LOCAL work_mem = '1GB';.Piège:
shared_buffersgigantesque sans HugePagesAllouer (ex) 64Go à
shared_bufferssans HugePages (statiques) force le noyau Linux à gérer cette mémoire via des pages standards (4KB), causant une surcharge massive de la TLB (Translation Lookaside Buffer) et de la fragmentation.Pratique: Activer les HugePages
Si
shared_buffers> 8-16Go, il est impératif de configurer les HugePages (2MB) dans l'OS et d'activerhuge_pages = ondans PostgreSQL. La performance mémoire sera bien meilleure.
Piège:
random_page_costmal régléLe défaut (
4.0) date des HDD rotatifs. Le planner *pense* qu'une lecture aléatoire (Index Scan) coûte 4x plus cher qu'une lecture séquentielle (Seq Scan). Sur SSD/NVMe/Cloud, c'est faux. Il va donc préférer des Seq Scan coûteux au lieu d'utiliser des index efficaces.Pratique: Baisser
random_page_costSur SSD/NVMe, baisser
random_page_costà1.1(ou1.0). Le planner réévaluera le coût des Index Scan et les choisira bien plus souvent, améliorant drastiquement les performances OLTP.Piège: Autovacuum trop timide sur grosses tables
Le défaut (ex:
scale_factor = 0.20) signifie qu'Autovacuum ne se lance que lorsque 20% de la table a changé. Sur une table de 500M de lignes, il faut attendre 100M de "tuples morts" (bloat) avant nettoyage. La table gonfle, les performances s'effondrent.Pratique: Calibrer Autovacuum par table
Le tuning d'Autovacuum doit être granulaire.
ALTER TABLE grosse_table SET (autovacuum_vacuum_scale_factor = 0.02, autovacuum_analyze_scale_factor = 0.01);
Cela déclenche le vacuum à 2% de changements et l'analyze à 1%, gardant la table propre et les statistiques à jour.
Piège: Tuning "aveugle"
Modifier 10 paramètres en même temps "parce qu'on l'a lu sur un blog". Si les performances s'améliorent (ou se dégradent), il est impossible de savoir quel paramètre est responsable. C'est la recette pour un désastre.
Pratique: Tests avant/après (Baseline)
Ne changer qu'un seul paramètre à la fois.
1. Mesurer la performance (Baseline).
2. Changer 1 paramètre (ex:work_mem).
3. Re-mesurer la performance.
4. Comparer. Le changement est-il bénéfique ? Si oui, on garde. Sinon, on annule.Piège: Sauvegardes non testées
Avoir un script de backup qui tourne en cron *ne signifie pas* que vous avez des sauvegardes fonctionnelles. Les RPO (Recovery Point Objective) et RTO (Recovery Time Objective) restent théoriques jusqu'au jour où la restauration échoue en pleine production.
Pratique: Tester la restauration périodiquement
La seule bonne sauvegarde est une sauvegarde *restaurée*. Planifier des tests de restauration (ex: trimestriels) sur un serveur à part. Chronométrer le temps de restauration (RTO réel) et vérifier l'intégrité des données (RPO réel).