PostgreSQL Systemmetriken

Stell dir vor, dein PostgreSQL-Server ist ein Restaurant und wir sind die Prüfer. Damit das Restaurant stabil läuft, müssen wir im Auge behalten, wie viele Zutaten (CPU, RAM, Disk) verbraucht werden, wie oft sie ausgehen und wer sie eigentlich konsumiert. Wenn wir das verpassen, nimmt unser "Restaurant" vielleicht zu viele Bestellungen an und kommt nicht mehr hinterher – oder crasht einfach mitten am Tag. Genau deshalb ist das Verständnis von Systemmetriken so wichtig.

Wichtige Metriken für das Monitoring von PostgreSQL:

1. CPU: Zeigt, wie viel Prozessorzeit für die Ausführung von Queries draufgeht.
2. RAM (Arbeitsspeicher): Zeigt, wie PostgreSQL den Arbeitsspeicher nutzt, inklusive Query-Caching.
3. Speicherplatz: Wahrscheinlich die offensichtlichste Metrik: Du kannst nicht mehr Daten speichern, als auf die Platte passen.

Unser Ziel: Wir lernen, wie man die Systemmetriken von PostgreSQL checkt und interpretiert, um Performance-Probleme und Ressourcen-Engpässe zu vermeiden.

CPU-Auslastung überwachen

Die CPU ist das Herz deines Servers. PostgreSQL kann die CPU sowohl für komplexe Queries als auch für Hintergrundjobs wie Autoanalyse und Autovacuum ordentlich beanspruchen. Wenn deine Datenbank wie ein unersättlicher Esser wirkt, der gierig CPU "frisst", ist es Zeit einzugreifen.

1. System-Tools nutzen.
   Finde zuerst raus, wie viel CPU-Zeit PostgreSQL auf Systemebene verbraucht. Unter Linux kannst du top oder htop nutzen.

Such nach dem PostgreSQL-Prozess (meist steht da der Name deiner Datenbank). Zum Beispiel: postgres: postgres [your_query].

Achte auf die Spalte %CPU. Wenn die ständig "durch die Decke geht", ist das ein Warnsignal.

2. CPU-Last direkt in PostgreSQL analysieren.

PostgreSQL bringt eigene Views fürs Monitoring mit. Am nützlichsten ist hier pg_stat_activity, das dir die aktiven Queries zeigt.

Beispiel-Query:

SELECT pid, usename, query, state, now() - query_start AS dauer
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY dauer DESC;

Was ist hier wichtig?

• state = 'active' zeigt nur die Queries, die gerade laufen.
• dauer zeigt, wie lange die Queries schon die CPU belasten.

Praxistipp:

Wenn du eine lange Query siehst, die eigentlich nicht so viel Zeit brauchen sollte, check mal, welche Indizes verwendet werden. Du kannst auch den Problemprozess mit pg_terminate_backend killen.

Beispiel zum Beenden:

SELECT pg_terminate_backend(pid)
FROM pg_stat_activity
WHERE state = 'active' AND dauer > interval '10 minutes';

RAM-Auslastung überwachen

RAM ist die zweitwichtigste Ressource für PostgreSQL, vor allem beim Caching von Daten. PostgreSQL nutzt den Arbeitsspeicher intensiv (über die Parameter work_mem und shared_buffers), um Operationen zu beschleunigen.

1. Wichtige PostgreSQL-Parameter für RAM-Nutzung:

• shared_buffers: Das ist der Hauptspeicherblock, den PostgreSQL nutzt. Normalerweise nimmt er 25-40% des gesamten RAMs des Servers ein.
• work_mem: Speicher für Sortier- und Hash-Operationen innerhalb einer Query. Je höher der Wert, desto mehr temporäre Operationen laufen im RAM (statt auf der Platte).

2. Aktuelle RAM-Einstellungen prüfen.

Um zu sehen, welche RAM-Settings gerade aktiv sind, führe aus:

SHOW shared_buffers;
SHOW work_mem;

Beispiel-Ausgabe:

1GB
4MB

Das heißt, der Server hat 1 GB für shared_buffers und jeweils 4 MB für jede Sortier-/Hash-Operation reserviert.

3. RAM-Monitoring mit pg_stat_activity

Du kannst checken, wie viel RAM die aktuellen Verbindungen nutzen. Dafür gibt’s diesen praktischen Query:

SELECT pid, usename, state, backend_start, pg_size_pretty(pg_backend_memory_contexts_size(pid)) AS ram_genutzt
FROM pg_stat_activity
WHERE state = 'active'
ORDER BY ram_genutzt DESC;

Mit diesem Query siehst du, wie viel RAM jede aktive Verbindung gerade verbraucht.

Tipp: Wenn eine Verbindung zu viel RAM zieht, schau nach, ob in der Query Sortier- oder Aggregations-Operationen stecken, die du optimieren kannst.

Speicherplatz überwachen

Die Platte ist der letzte große Ressourcenpool für PostgreSQL. Selbst wenn du genug RAM und CPU hast, braucht PostgreSQL Speicherplatz für Daten, Transaktionslogs (WAL) und temporäre Dateien.

1. Datenbankgröße prüfen.

Fangen wir einfach an: Wie groß ist die Datenbank?

SELECT pg_size_pretty(pg_database_size(current_database())) AS db_groesse;

Was macht dieser Query?

Er zeigt die Gesamtgröße der aktuellen Datenbank in einem lesbaren Format (MB, GB).

2. Größe von Tabellen und Indizes prüfen.

Um die "Schwergewichte" in deiner Datenbank zu finden, nutze:

SELECT relname AS tabellenname, pg_size_pretty(pg_total_relation_size(relid)) AS gesamtgroesse
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

Beispiel-Ausgabe:

3. WAL (Transaktionslogs) überwachen.

Wenn deine Datenbank viel zu tun hat, wachsen die Transaktionslogs schnell. So checkst du deren Größe:

SELECT pg_size_pretty(pg_xlog_location_diff(pg_current_wal_lsn(), '0/0')) AS wal_groesse;

Fazit

Jetzt hast du die Tools und das Know-how, um die Systemmetriken von PostgreSQL im Blick zu behalten:

1. Nutze htop oder pg_stat_activity für das CPU-Monitoring.
2. Stell shared_buffers und work_mem optimal für deinen RAM ein.
3. Check regelmäßig die Größe von Datenbank, Tabellen und Indizes, damit dir der Speicherplatz nicht ausgeht.

Mit diesen Skills kannst du böse Überraschungen vermeiden und deinen PostgreSQL-Server fit halten. Denk dran: Gut gemanagte Ressourcen machen dein Produkt zum Liebling deiner Nutzer:innen!