📋 10) Check-list rapide
Objectif : centraliser les entrées de cadrage pour calculer rapidement les valeurs initiales de tuning.
Ressources & Infra
RAM totale, type de serveur (VM, bare-metal) et configuration de base de l'OS (THP, FS).
Profil & Config PG
Profil applicatif (OLTP/OLAP), connexions, mémoire (work_mem) et configuration WAL.
Planner & Suivi
Ajustements du planner (coûts I/O), calibrage d'Autovacuum et vérification de l'observabilité.
Checklist Entrées
→ shared_buffers = ___ Go
→ effective_cache_size = ___ Go.
→ scheduler I/O ___
→ NUMA policy ___
→ credits CPU ___.
→ THP off ? Y/N
→ HugePages ? Y/N
→ FS ___ with noatime ? Y/N
RAM
Calcul initial :
1. RAM_PG = RAM Totale - (RAM OS + Cache FS)
(ex: 128Go - 32Go = 96Go)
2. shared_buffers = 25% de RAM_PG
(ex: 96Go * 0.25 = 24Go)
3. effective_cache_size = 75% de RAM_PG
(ex: 96Go * 0.75 = 72Go)
Type de serveur
Le type d'hôte influence les goulots d'étranglement :
• Bare-metal: Contrôle total, attention à NUMA.
• VM (VMware/KVM): Risque de "noisy neighbors", sur-allocation (overcommit) CPU/RAM ?
• Cloud (AWS/GCP/Azure): Attention aux crédits CPU (type 'T') et au bursting I/O (ex: EBS gp2 vs gp3/io1).
OS & FS
Les réglages OS sont cruciaux :
• THP (Transparent HugePages) doit être sur never pour éviter les stalls.
• HugePages (statiques) sont recommandées si shared_buffers > 8-16Go.
• FS (XFS/ext4): Doit être monté avec noatime pour réduire les écritures inutiles.
Checklist Entrées
→ dataset actif ___ Go
→ connexions simultanées ___
work_mem cible ___ MB
maintenance_work_mem ___ MB.
→ checkpoint_timeout ___
→ sync_commit ___.
Profil Applicatif
• OLTP: (Transactions) Haut volume de petites requêtes (SELECT/INSERT/UPDATE). Vise la latence basse.
• OLAP: (Analyse) Faible volume de grosses requêtes (JOINs, agrégats). Vise le débit.
• Mixte: (Hybride) Le plus difficile. Nécessite de protéger l'OLTP de l'OLAP (ex: via work_mem).
Connexions & Mémoire
• Pooler (PgBouncer): Obligatoire si > 100-200 connexions.
• max_connections (PG): Doit être bas si PgBouncer est utilisé (ex: 100).
• work_mem: Alloué *par opération* (sort, join).
(RAM_PG - shared_buffers) / max_connections est un point de départ.
• maintenance_work_mem: Augmenter (ex: 1-2Go) pour accélérer CREATE INDEX, VACUUM.
WAL (Write-Ahead Log)
• max_wal_size: Augmenter (ex: 16-64Go) pour lisser les checkpoints et réduire les "pics" d'I/O.
• sync_commit: on (défaut) garantit la durabilité (ACID). off est plus rapide mais risque une perte de données (quelques ms) en cas de crash.
Checklist Entrées
→ effective_io_concurrency ___
→ parallélisme ___
→ JIT ___.
→ scale_factor (vacuum/analyze) = ___ / ___
→ naptime ___ s
→ workers ___.
→ log_min_duration_statement ___ ms
→ dashboards OK.
Planner (Planificateur)
• random_page_cost: Le plus important. 4.0 (défaut) est pour les HDD. Mettre à 1.1 ou 1.0 pour SSD/NVMe/Cloud pour favoriser les index.
• effective_io_concurrency: Mettre à 200-300 si le stockage sous-jacent est rapide (ex: NVMe RAID).
• JIT: (Just-In-Time) Utile pour OLAP (requêtes longues). Peut ajouter un léger overhead pour l'OLTP.
Autovacuum
Le démon de nettoyage. Les défauts sont inadaptés aux grosses tables (scale_factor=0.20 → 20% de changement !).
• Il faut régler par table: ALTER TABLE big_table SET (autovacuum_vacuum_scale_factor = 0.02); (ex: 2%)
Observabilité
• pg_stat_statements: Doit être activé (shared_preload_libraries). C'est le seul moyen de savoir quelles requêtes sont lentes.
• log_min_duration_statement: Mettre à 250ms ou 500ms. 0 logue tout (trop), -1 (défaut) ne logue rien.