Une base PostgreSQL lente sous pression de production invite à deviner, et deviner est la façon dont les rescues tournent mal. Ajouter un index, monter un réglage mémoire ou redémarrer un serveur peut masquer le vrai goulot et introduire un nouveau risque. Le travail qui tient vraiment part de preuves et change une chose à la fois.
Quand le problème apparaît
L’appel vient généralement quand quelque chose de visible casse : les pages timeout au pic, les background jobs s’accumulent, un rapport nocturne ne se termine plus, ou le nombre de connexions grimpe jusqu’à ce que l’application ne puisse plus ouvrir de session. Souvent rien n’a changé dans la requête, seulement le volume de données. Parfois un déploiement a ajouté une requête d’apparence inoffensive qui fait un sequential scan sur une table montée en silence à des dizaines de millions de lignes. La première tâche n’est pas de réparer. C’est de décrire l’incident précisément.
Modes de défaillance courants
Tuner les réglages avant de lire les requêtes. Monter work_mem ou shared_buffers paraît productif, mais si un plan de requête est faux, le bouton global ne fait que répartir le coût. D’abord les preuves, ensuite les réglages.
Indexer à l’intuition. Des index qui ne correspondent à aucune requête réelle ajoutent de l’overhead d’écriture et du bloat sans aider les lectures. Les index inutilisés sont un coût, pas une assurance.
Ignorer locks et longues transactions. Une seule transaction longue peut bloquer l’autovacuum, tenir des locks et figer tout ce qui suit. Le symptôme lent est souvent un problème de locks déguisé en problème de performance.
Laisser dériver bloat et autovacuum. Tables et index gonflent quand l’autovacuum ne suit pas, et le bloat dégrade lentement chaque requête. C’est invisible jusqu’à ce qu’on le mesure.
Changer la production à l’aveugle. Un correctif qui marche sur un petit jeu de données peut se comporter tout autrement sur des données de taille production. Sans test proche de la production, “ ça marchait en local “ ne rassure pas.
Comment enquêter
Partez de la forme de l’incident, puis resserrez avec des preuves.
Décrivez le symptôme précisément
Pages lentes, jobs retardés, lock waits, CPU élevé, pression IO, épuisement des connexions ou latence croissante mènent chacun sur un chemin différent. Nommer le symptôme resserre la recherche avant de toucher quoi que ce soit.
Lisez les requêtes
Trouvez les requêtes lentes, regardez leurs plans d’exécution, comparez les estimations de lignes à la réalité, et cherchez index manquants, index inutilisés et full scans répétés. Une poignée de plans raconte souvent plus clairement que tout conseil de tuning générique.
Vérifiez la couche opérationnelle
Inspectez locks, longues transactions, santé de l’autovacuum, bloat des tables et index, comportement des migrations récentes, connection pooling et pression des background jobs. Une base lente est souvent un problème système, pas seulement un problème SQL.
Checklist opérationnelle
- L’incident a un symptôme nommé, pas seulement “ la base est lente “.
- Les requêtes lentes sont identifiées à partir de preuves, plans capturés.
- Les estimations de lignes sont comparées au réel pour repérer des statistiques périmées.
- Locks et longues transactions ont été inclus ou exclus.
- Santé de l’autovacuum et bloat sont mesurés, pas supposés.
- Connection pooling et concurrence des jobs sont pris en compte.
- Chaque changement proposé a un rollback et un moyen de vérification.
Un chemin sûr
Mesurer, isoler un goulot, changer la plus petite chose utile, vérifier en conditions proches de la production et garder des options de rollback claires. Résistez à l’envie d’appliquer cinq changements à la fois ; si quelque chose s’améliore, vous ne saurez pas lequel a agi, et si quelque chose casse, lequel défaire. Un changement, une mesure, on recommence.
Ce travail de base arrive généralement dans le cadre de la modernisation et du rescue d’infrastructure. Il se connecte à nos services plus larges et à la pensée de modernisation de la checklist de modernisation Rails. Si une base de production est sous pression, dites-nous ce qui casse, et nous partirons des preuves.
Cet article est une orientation d’ingénierie générale, pas un conseil pour un système précis. Un vrai rescue doit toujours commencer par des mesures issues de votre propre environnement de production.