Kapazitätsplanung und Bloat-Prüfungen
Prognostizieren Sie das Wachstum von Festplattenbedarf und IOPS, prüfen Sie Tabellen- und Index-Bloat regelmäßig und planen Sie Upgrades, bevor die Kapazitätsgrenze erreicht ist.
Kapazitätsplanung und Bloat-Prüfungen ist eine kostenlose SQL Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des SQL Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was Sie prognostizieren sollten
Um Ihre Datenbank für die nächsten 6–12 Monate zu dimensionieren, müssen Sie Folgendes prognostizieren:
- Festplattennutzung (Daten + WAL + Indizes)
- IOPS-Bedarf
- Arbeitssatz im RAM
- Anzahl der Verbindungen
Festplattenwachstum
Ermitteln Sie den Trend des jüngsten Wachstums:
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;Wachstum pro Tabelle verfolgen
Planen Sie einen Job zur Protokollierung von Metriken und stellen Sie die Ergebnisse grafisch dar:
INSERT INTO size_history (ts, tablename, size_bytes)
SELECT NOW(), relname, pg_total_relation_size(oid)
FROM pg_class WHERE relkind = 'r';IOPS schätzen
Tabellen mit hoher Lese-I/O-Aktivität finden Sie in 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;RAM dimensionieren
shared_buffers ≈ 25 % des RAM. effective_cache_size ≈ 75 % (Hinweis für den Planer, keine Speicherzuweisung). work_mem pro Verbindung × Anzahl der Verbindungen sollte den verfügbaren RAM nicht überschreiten.
Bloat prüfen
Finden Sie die Tabellen mit den meisten toten Zeilen:
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;Index-Bloat
Verwenden Sie pgstattuple oder integrierte Tools:
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;Ungenutzte Indizes
Finden und entfernen Sie sie — sie verursachen zusätzliche Schreibvorgänge:
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;Verbindungen prüfen
Wie viele Clients verbunden sind und welchen Status sie haben:
SELECT datname, usename, application_name, state, COUNT(*)
FROM pg_stat_activity
GROUP BY 1,2,3,4 ORDER BY 5 DESC;Lange Transaktionen
Die Ursache für einen ins Stocken geratenen Vacuum-Vorgang:
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 und Archive
Überwachen Sie die WAL-Erzeugungsrate, um den benötigten Archivspeicher zu dimensionieren:
SELECT pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), '0/0')) AS total_wal_generated;Failover planen
Der Festplattenspeicher der Replik sollte dem des primären Servers entsprechen. Stellen Sie sicher, dass die Aufholrate der Replik mindestens der Schreibrate des primären Servers entspricht.
Zusammenfassung
Kapazitätsplanung bedeutet, die richtigen Metriken grafisch darzustellen.
- Größenzunahme pro Tabelle
- Anteil toter Zeilen
- Ungenutzte Indizes
- Lange Transaktionen, die Vacuum blockieren
- Anzahl der Verbindungen
Kurzer Check
Welche Ansicht fragen Sie ab, um für die Vacuum-Planung die Tabellen mit den meisten toten Zeilen zu finden?
Lerne SQL mit einem KI-Tutor — kostenlos
Schreibe und führe echten Code in deinem Browser aus, bekomme sofortige Hilfe von einem 24/7 KI-Tutor und setze dein Lernen im Web oder in der App fort.
- Kurse
- 46
- Lektionen
- 183
Häufig gestellte Fragen
Ist die Lektion „Kapazitätsplanung und Bloat-Prüfungen“ kostenlos?
Ja — der vollständige Text von „Kapazitätsplanung und Bloat-Prüfungen“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des SQL Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der SQL Academy-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Kapazitätsplanung und Bloat-Prüfungen“?
Prognostizieren Sie das Wachstum von Festplattenbedarf und IOPS, prüfen Sie Tabellen- und Index-Bloat regelmäßig und planen Sie Upgrades, bevor die Kapazitätsgrenze erreicht ist. Du übst SQL Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um SQL Academy zu starten?
Keine Vorkenntnisse erforderlich. SQL Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Kapazitätsplanung und Bloat-Prüfungen“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser SQL Academy-Lektion Code schreiben und ausführen?
Ja. Jede SQL Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- pg_stat_statements: Wichtigste Abfragen
- pgBadger für die Log-Analyse
- Connection Pooling: PgBouncer
- Kapazitätsplanung und Bloat-Prüfungen