PostgreSQL : configuration essentielle

Prérequis (cursus dev) : serveur Postgres, maîtriser psql.

Pourquoi

Postgres par défaut est « raisonnable partout, optimal nulle part ». Une dizaine de paramètres font 80 % du chemin entre une base qui rame et une base saine — sans toucher au code.

Concepts

• Mémoire : shared_buffers (25 % RAM, cache PG), work_mem (tri/jointures par opération ! ×100 opérations = ×100 la valeur — prudence), maintenance_work_mem (VACUUM, CREATE INDEX : généreux sans risque).
• Écritures : wal_buffers, checkpoint_timeout/max_wal_size (checkpoints trop fréquents = vagues d'écriture). Symptôme : lenteurs périodiques régulières comme une horloge.
• Connexions : max_connections (chaque connexion = processus + RAM !). 500 connexions directes = folie : pooler (PgBouncer en transaction pooling) devant.
• Logs utiles : log_min_duration_statement = 500ms (lentes), log_connections/disconnections (pics), log_lock_waits = on (verrous qui font attendre).

Exemple : dimensionner une 8 Go

shared_buffers = 2GB
work_mem = 16MB        # prudent : × N opérations simultanées
maintenance_work_mem = 512MB
max_connections = 100  # + PgBouncer devant

Cas réel

work_mem à 256 Mo « pour aller vite » sur 200 connexions : 51 Go virtuels, swap, OOM-killer qui tue Postgres en pleine journée. Retour à 16 Mo + index manquants corrigés : plus rapide ET stable.

Pièges

• Copier une conf « 64 Go » sur 4 Go : chaque paramètre dépend de LA machine (outil : PGTune en point de départ, jamais en vérité).
• Changer 5 paramètres d'un coup : on ne sait plus lequel a aidé. Un par un, mesuré.
• max_connections énorme au lieu d'un pooler : processus + RAM par connexion, effondrement au-delà de ~200-300.

À retenir

shared_buffers 25 %, work_mem prudent (× opérations), pooler au-delà de ~100 connexions, logs lentes activés.