Planification de capacité et audits du gonflement
Prévoyez la croissance du stockage et des IOPS, contrôlez régulièrement le gonflement des tables et des index et planifiez les mises à niveau avant de manquer de ressources.
Planification de capacité et audits du gonflement est une leçon SQL Academy gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage SQL Academy, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours SQL Academy comprend 4 leçons au total.
Éléments à prévoir
Pour dimensionner votre base de données sur les 6 à 12 prochains mois, vous devez projeter :
- Utilisation du disque (données + WAL + index)
- Demande en IOPS
- Ensemble de travail en RAM
- Nombre de connexions
Croissance du disque
Tracez la tendance de la croissance récente :
SELECT pg_size_pretty(pg_database_size(current_database()));
SELECT pg_size_pretty(pg_total_relation_size(t.oid)) AS total,
relname
FROM pg_class t
WHERE relkind = 'r'
ORDER BY pg_total_relation_size(t.oid) DESC LIMIT 20;Suivi de la croissance par table
Planifiez une tâche de journalisation des métriques et représentez-les graphiquement :
INSERT INTO size_history (ts, tablename, size_bytes)
SELECT NOW(), relname, pg_total_relation_size(oid)
FROM pg_class WHERE relkind = 'r';Estimation des IOPS
Les tables très sollicitées en lecture apparaissent dans pg_stat_user_tables :
SELECT relname, seq_tup_read, idx_tup_fetch,
seq_tup_read + idx_tup_fetch AS total_reads
FROM pg_stat_user_tables
ORDER BY total_reads DESC LIMIT 20;Dimensionnement de la RAM
shared_buffers ≈ 25 % de la RAM. effective_cache_size ≈ 75 % (indication pour le planificateur, pas une allocation). work_mem par connexion × nombre de connexions ne doit pas dépasser la RAM disponible.
Audit du gonflement
Repérez les tables contenant le plus de lignes mortes :
SELECT relname,
n_live_tup,
n_dead_tup,
round(n_dead_tup::numeric / NULLIF(n_live_tup, 0), 2) AS dead_ratio,
last_autovacuum
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;Gonflement des index
Utilisez pgstattuple ou les outils intégrés :
CREATE EXTENSION pgstattuple;
SELECT relname,
pg_size_pretty(pg_relation_size(indexrelid)) AS size,
(pgstatindex(indexrelid::regclass)).leaf_fragmentation
FROM pg_stat_user_indexes
ORDER BY pg_relation_size(indexrelid) DESC LIMIT 20;Index inutilisés
Repérez-les et supprimez-les : ils pénalisent les écritures :
SELECT schemaname, relname, indexrelname,
pg_size_pretty(pg_relation_size(indexrelid))
FROM pg_stat_user_indexes
WHERE idx_scan = 0
AND indexrelname NOT LIKE '%_pkey'
ORDER BY pg_relation_size(indexrelid) DESC;Audit des connexions
Combien de clients sont connectés et dans quel état :
SELECT datname, usename, application_name, state, COUNT(*)
FROM pg_stat_activity
GROUP BY 1,2,3,4 ORDER BY 5 DESC;Transactions longues
La cause de la saturation du nettoyage automatique :
SELECT pid, state, xact_start, NOW() - xact_start AS xact_age, query
FROM pg_stat_activity
WHERE xact_start IS NOT NULL
ORDER BY xact_age DESC NULLS LAST LIMIT 20;WAL et archives
Surveillez le taux de génération du WAL pour dimensionner le stockage des archives :
SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0')) AS total_wal_generated;Prévoir le basculement
Le disque de la réplique doit être de taille équivalente à celui du serveur primaire. Vérifiez que le taux de rattrapage de la réplique est supérieur ou égal au taux d’écriture du serveur primaire.
Récapitulatif
La planification de capacité consiste à représenter graphiquement les bonnes métriques.
- Croissance de la taille par table
- Ratio de lignes mortes
- Index inutilisés
- Transactions longues bloquant le nettoyage automatique
- Nombre de connexions
Vérification rapide
Quelle vue interrogez-vous pour trouver les tables contenant le plus de lignes mortes lors de la planification du nettoyage automatique ?
Questions Fréquemment Posées
La leçon « Planification de capacité et audits du gonflement » est-elle gratuite ?
Oui — le texte complet de « Planification de capacité et audits du gonflement » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours SQL Academy, passe à CoddyKit PRO. Le cours SQL Academy comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Planification de capacité et audits du gonflement » ?
Prévoyez la croissance du stockage et des IOPS, contrôlez régulièrement le gonflement des tables et des index et planifiez les mises à niveau avant de manquer de ressources. Tu pratiques SQL Academy avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer SQL Academy ?
Aucune expérience préalable n'est requise. SQL Academy sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.
Combien de temps prend la leçon « Planification de capacité et audits du gonflement » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon SQL Academy ?
Oui. Chaque leçon SQL Academy inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- pg_stat_statements : requêtes principales
- pgBadger pour analyser les journaux
- Mise en commun des connexions : PgBouncer
- Planification de capacité et audits du gonflement