PIDSTAT Linux: CPU- und Speicherverbrauch einzelner Prozesse analysieren

Mit pidstat Linux messe ich CPU-, Speicher-, I/O- und Thread-Aktivität je Prozess in festen Intervallen und erkenne dadurch Trends statt Momentaufnahmen. So finde ich Engpässe zuverlässig, ordne sie einer PID oder einem Kommando zu und entscheide, ob CPU, RAM, I/O oder Kontextwechsel die Ursache bilden.

Zentrale Punkte

• Intervall-Messung: Zeitreihen je Prozess statt reiner Momentaufnahme.
• Breite Abdeckung: CPU, Speicher, I/O, Threads und Kontextwechsel.
• Gezieltes Filtern: Per PID oder Kommando fokussiert beobachten.
• Einfache Nutzung: sysstat installieren, direkt starten.
• Praxisnutzen: Lastspitzen, Leaks und I/O-Engpässe schnell zuordnen.

Was ist pidstat? Kurz erklärt

Ich nutze pidstat, um die Ressourcennutzung einzelner Prozesse über Zeit sichtbar zu machen. Das Werkzeug gehört zum Paket sysstat und liefert je Prozess Zahlen zu CPU, Speicher, I/O, Threads und Kontextwechseln. Im Gegensatz zu top erhalte ich keine flüchtige Sicht, sondern fortlaufende Messpunkte in Intervallen. Dadurch erkenne ich Muster wie periodische Spikes, Dauerlast oder schleichendes Wachstum. Diese Zeitinformation hilft mir, Ursachen klar einem Prozess zuzuordnen und nicht im Rauschen einer Momentaufnahme zu verlieren.

Installation und schnelle Inbetriebnahme

Ich installiere sysstat mit dem Paketmanager meiner Distribution und starte pidstat sofort ohne Zusatzkonfiguration. Die Grundsyntax bleibt einfach: pidstat [Optionen] [Intervall] [Anzahl]. Ohne Optionen zeigt das Tool CPU-Werte je Prozess, mit Intervall wiederholt es die Messungen fortlaufend. Beispiel: pidstat 2 10 sammelt zehn Durchläufe alle zwei Sekunden. So baue ich mir schnell eine belastbare Zeitleiste für die weitere Analyse auf.

CPU-Analyse: Last pro Prozess sichtbar machen

Für CPU-Fragen starte ich pidstat mit -u, etwa pidstat -u 1 für Sekundentakt. Die Spalten %usr, %system und %CPU zeigen mir, wie viel Nutzer- und Kernelzeit ein Prozess beansprucht. Benötige ich den Fokus auf eine Anwendung, nutze ich -p <PID> oder -C <kommando> für Namensfilter. Steigt %system stark, prüfe ich Systemaufrufe oder I/O-Einflüsse; dominiert %usr, liegt die Arbeit im User-Space. Für weiterführende Abrechnung pro Prozess verweise ich bei Bedarf ergänzend auf Prozess-Accounting, um Nutzungsdaten strukturiert auszuwerten.

Speicherverbrauch gezielt prüfen

Bei RAM-Themen liefert -r wertvolle Einblicke, etwa mit pidstat -r -p 1234 1. Ich beobachte, wie sich virtuell belegter und residenter Speicher über Minuten entwickelt und ob Page Faults ansteigen. Nimmt der Verbrauch in kleinen Schritten stetig zu, erkenne ich mögliche Leaks frühzeitig. Bleibt der Bedarf konstant und steigt nur in kurzen Phasen, deutet das auf legitimes Caching hin. Durch die Intervallmessung trenne ich Ausreißer sauber von echten Trends.

I/O- und Kontextwechsel verstehen

Mit -d zeige ich Lese- und Schreibaktivität je Prozess und finde damit Verursacher von hohen Wartezeiten am Datenträger. Hohe Transferraten in Kombination mit steigenden Latenzen lassen auf Engpässe im Storage schließen. Ergänzend prüfe ich mit -w die Kontextwechsel pro Sekunde, weil exzessive Wechsel unnötigen Overhead erzeugen können. Viele freiwillige Wechsel (vswch/s) deuten auf Synchronisation; viele erzwungene Wechsel (cswch/s) auf heftige Konkurrenz um CPU-Zeit. So erkenne ich ineffiziente Workloads, die ich gezielt entschärfe.

Threads überwachen und Hotspots finden

Nutze ich -t, liefert pidstat pro Prozess zusätzlich Thread-Werte. Damit sehe ich, ob einzelne Worker einer Anwendung aus dem Rahmen fallen. Bei Java, PHP-FPM, Datenbanken oder Queue-Workern erkenne ich so Threads, die CPU binden oder Speicher wachsen lassen. Entdecke ich Unwuchten, passe ich Thread-Pools, Affinitäten oder Limits an. Diese Sicht hilft mir, nicht nur Prozesse, sondern auch deren interne Parallelität zu optimieren.

Wichtige Optionen im Überblick

Ich nutze die Kernschalter gezielt, um Analysen fokussiert zu fahren und Ausgaben lesbar zu halten. Die folgende Tabelle fasst die zentralen Optionen und typische Einsätze kompakt zusammen. So wähle ich schnell den passenden Schalter für CPU, Speicher, I/O, Threads oder Filter. Beispiele helfen mir, ohne Umwege zu starten. Jede Zeile liefert mir einen klaren Hinweis auf den Einsatzzweck.

Option	Funktion	Beispiel
-u	CPU-Nutzung je Prozess anzeigen	pidstat -u 1
-r	Speicher- und Page-Fault-Werte	pidstat -r -p 1234 2
-d	I/O-Aktivität lesen/schreiben	pidstat -d 1
-w	Kontextwechsel je Prozess	pidstat -w -p 1234 1
-t	Thread-Statistiken einblenden	pidstat -t -p 1234 1
-p <PID>	Auf konkrete Prozess-ID begrenzen	pidstat -u -p 1234 1
-C <name>	Prozesse per Kommando filtern	pidstat -C php-fpm 2

Filter, Intervalle und zielgerichtete Beobachtung

Ich plane Messungen mit Intervallen, die zur Fragestellung passen: Sekunden für Spikes, Minuten für Langläufer. Über -p und -C reduziere ich die Ausgabe auf relevante Prozesse und halte die Konsole übersichtlich. pidstat 2 10 eignet sich gut für kurze Proben; ohne Anzahl messe ich dauerhaft, bis ich abbreche. Für wiederkehrende Checks hinterlege ich Kommandos in Skripten und dokumentiere die Baseline eines Systems. Diese Routine spart Zeit, wenn Lastprobleme erneut auftreten.

Vergleich mit top, ps und Co.

Für einen Schnellblick nutze ich top oder ps, doch für Verlauf und Detailtiefe greife ich zu pidstat. Intervallwerte ermöglichen mir, Ursachen über Zeit zu erkennen statt nur Symptome zu sehen. Brauche ich tieferen Einblick in CPU-Flaschenhälse, ergänze ich die Analyse mit Linux perf für Stichproben der Call-Stacks. So kombiniere ich Prozessstatistiken mit Profiling, wenn reine Auslastungswerte nicht reichen. Diese Kombination liefert mir schnelle Hinweise und eine fundierte Diagnose.

Praxis-Shortcuts für den Alltag

Ich halte mir bewährte Kommandos bereit und variiere sie nach Lage der Dinge für Produktionssysteme. CPU-Last live: pidstat -u 1. Speicher mit Fokus: pidstat -r -p <PID> 2. I/O-Engpass prüfen: pidstat -d 1. Threads im Blick: pidstat -t -p <PID> 1. Für tiefergehende Systeminstrumentierung ziehe ich ergänzend bpftrace Tipps heran, wenn Kernel-Ereignisse Spotlight brauchen.

Ausgabe richtig lesen: Zeitachsen und Mehrkern-Systeme

Ich achte darauf, wie pidstat die Zeitbezüge setzt: Der erste Messblock zeigt Standardmäßig Durchschnittswerte seit dem Start des Prozesses (oder seit dem Systemstart), alle folgenden Blöcke beziehen sich auf das gewählte Intervall. Für feine Analysen ignoriere ich oft den ersten Block und betrachte nur die zeitlich vergleichbaren Intervallwerte.

Auf Mehrkern-Systemen interpretiere ich %CPU stets im Kontext der verfügbaren Kerne. Ein einzelner Prozess kann auf einem 8-Core-Host theoretisch bis zu 800% erreichen, wenn er über mehrere Threads skaliert. Hohe %system-Werte lassen mich in Richtung Syscalls, Lock-Contention oder I/O-Wartepfade denken; hohe %usr-Werte deuten auf rechenintensive Routinen im User-Space hin. Der Zeitstempel vor jeder Zeile macht Ausreißer im Verlauf klar erkennbar und erleichtert die Korrelation mit Logs oder Metriken anderer Quellen.

Methodik: Hypothesen bilden, Messfenster wählen

Ich starte nie blind, sondern formuliere eine Hypothese zur Ursache: „CPU-bound im User-Space“, „I/O-Queue staut“, „Speicher wächst stetig“. Daraus leite ich das Messfenster ab: Bei kurzen Spikes nutze ich 1–2 Sekunden Intervalle, bei Langläufern eher 10–60 Sekunden. Wichtig ist, das Fenster an die Dynamik des Systems anzupassen, um weder Details zu verlieren noch unnötig viel Rauschen zu sammeln.

Ich messe außerdem vor und nach Änderungen (z. B. Release, Config-Tuning), um Effekte in den Metriken sichtbar zu machen. Eine saubere Baseline je Umgebung (DEV, STAGE, PROD) hilft mir, echte Abweichungen von normalen Mustern zu unterscheiden.

Dauerhafte Aufzeichnung und Nachbereitung

Bei schwer greifbaren Problemen zeichne ich für einen definierten Zeitraum mit und werte später aus. Beispiel: pidstat -udwt 2 900 > /var/log/pidstat_$(date +%F_%H%M).log sammelt 30 Minuten lang CPU, I/O, Kontextwechsel und Threads im 2‑Sekundentakt. Die strukturierte Textausgabe kann ich mit grep, awk oder einem kurzen Skript post-processen, Peaks markieren und auffällige PIDs extrahieren. Für wiederkehrende Beobachtungen plane ich ein Rotationsschema und sichere nur relevante Zeitfenster, um Platz zu sparen.

Wenn ich mehrere Blickwinkel brauche, kombiniere ich Schalter in einem Lauf, statt mehrere Tools parallel zu starten. Das hält die Messergebnisse synchron und erleichtert die Auswertung.

Container, Namespaces und PIDs

In Container-Umgebungen gilt: PIDs sind namespaced. Messe ich im Host, sehe ich Host-PIDs; messe ich im Container, sehe ich Container-PIDs. Zur eindeutigen Zuordnung filtere ich daher lieber per Kommando-Name mit -C als mit einer einzelnen PID, die sich nach einem Neustart ändert. Arbeite ich hostseitig, ergänze ich den Prozesskontext (z. B. via Service- oder Pod-Namen in Logs), um Messwerte später sauber einem Workload zuzuordnen. Für langlaufende Aufzeichnungen vermeide ich die PID-Falle (PID-Reuse) ebenfalls durch Namensfilter oder durch Begleit-Logs, die die PID-Lebensdauer dokumentieren.

Produktionssicher messen: Overhead, Rechte, Datenschutz

Overhead: pidstat liest primär aus /proc und erzeugt nur geringen Messaufwand. Bei sehr kurzen Intervallen auf stark belasteten Hosts erhöhe ich das Intervall minimal (z. B. von 1 auf 2 Sekunden), um die Wirkung auf die CPU weiter zu senken. Ich messe fokussiert (Filter!) statt „alles, überall“.

Rechte & Sicherheit: Je nach Systemkonfiguration (hidepid auf /proc) sind Details nicht für alle Nutzer sichtbar. Auf Produktion arbeite ich bei Bedarf mit erhöhten Rechten, halte die Messdauer klein und prüfe, ob das Anzeigen vollständiger Kommandozeilen sensible Parameter offenlegen könnte. Logs mit Diagnosedaten gehören nur dorthin, wo sie sicher gespeichert und gelöscht werden.

Typische Muster schnell erkennen

• Hohes %system bei moderater %usr: Hinweis auf Kernel-nahe Hotspots (intensiver Syscall-Gebrauch, Lock-Contention, Netzwerk-/Storage-Treiberpfade). Ich korreliere das mit I/O-Werten und Kontextwechseln.
• Viele erzwungene Kontextwechsel (cswch/s): Starker Wettkampf um CPU-Zeit, häufig durch zu knappe CPU-Resourcen oder zu viele aktive Threads. Drosseln, Pool-Größen anpassen oder Affinitäten prüfen.
• Viele freiwillige Kontextwechsel (vswch/s): Ausgeprägte Synchronisation oder yield-basierte Warteschleifen. Ich hinterfrage Locks, Backoff-Strategien und Thread-Pool-Verhalten.
• Stetig steigender Speicher: Verdacht auf Leak. Ich verifiziere, ob Page Faults (insbesondere majflt) zunehmen und ob der Prozess Speicher nach Lastspitzen wieder freigibt. Tut er es nicht, belege ich das mit einer längeren Intervallmessung.
• Hohe I/O-Transferraten bei langsamem Durchsatz im System: Kombiniert mit Wartezeiten deuten die Prozess-I/O-Werte auf Engpässe im darunterliegenden Storage-Stack. Ich priorisiere I/O-optimierende Maßnahmen (Batching, Caching, asynchrone I/O).
• Einzelne Threads stechen heraus: Mit -t erkenne ich den „Hot Thread“ und justiere den Thread-Pool oder untersuche gezielt dessen Codepfad.

Workflows aus der Praxis

CPU-bound identifizieren: Zuerst pidstat -u 1 global, dann gezielt mit -p oder -C. Steigen %usr, suche ich den Hot Thread mit -t und werte anschließend, falls nötig, per Sampling-Profiler aus. Dominieren %system, werfe ich zusätzlich einen Blick auf I/O und Kontextwechsel.

Speicher-Leak erhärten: Über mehrere Minuten mit pidstat -r -p <PID> 5 beobachten. Ich dokumentiere einen stetigen Zuwachs ohne Rückgang nach Lastphasen. Parallel prüfe ich, ob Page-Fault-Raten oder I/O-Muster das Verhalten erklären. Bleibt der Trend ohne legitime Begründung bestehen, ist das ein klarer Leak-Indikator.

I/O-Stau enttarnen: Mit pidstat -d 1 erkenne ich Schreib-/Lese-Hotspots. Sehe ich signifikante Schreiblast durch wenige Prozesse, fokussiere ich auf deren Flush-/Sync-Pfade und Batch-Größen. Korrelation mit Kontextwechseln hilft mir zu sehen, ob die CPU gleichzeitig unter Druck gerät.

Thread-Unwucht beheben: pidstat -t -p <PID> 1 zeigt mir pro Thread Last und Kontextwechsel. Wird ein Worker deutlich heißer als der Rest, passe ich Pool-Größen, Aufgabenverteilung oder Affinity an und prüfe, ob sich die Verteilung in den nächsten Intervallen normalisiert.

Grenzen von pidstat und sinnvolle Ergänzungen

pidstat zeigt was Ressourcen verbraucht und wann es geschieht – es erklärt nicht automatisch das warum im Codepfad. Für das „Warum“ nutze ich ergänzend Sampling-Profiler oder Kernel-Tracepunkte. Bei Speicherfragen beleuchtet pidstat Trends, nicht aber Objektlebenszyklen. Ich sehe pidstat daher als First-Responder, der mir die Problembereiche mit minimalem Aufwand eingrenzt. Dort, wo reine Auslastungswerte nicht mehr genügen, vertiefe ich die Analyse gezielt mit den bereits genannten Werkzeugen.

Checkliste für den Schnellstart

• Fragestellung schärfen: CPU, RAM, I/O, Threads oder Kontextwechsel?
• Intervall wählen: Sekunden für Spikes, Minuten für Trends.
• Filter setzen: -p <PID> oder -C <kommando> nutzen, um die Ausgabe schlank zu halten.
• Erst Überblick, dann Fokus: Global starten, auffällige Prozesse herausfiltern.
• Ersten Block einordnen: Erste Zeile ist seit Start gemittelt, danach Intervallwerte vergleichen.
• Messdauer begrenzen: Genug Daten für Trends sammeln, aber Logs im Griff behalten.
• Dokumentieren: Baseline, Hypothese, Messparameter und Beobachtungen festhalten – das macht Analysen reproduzierbar.

Kurz zusammengefasst

Mit pidstat erhalte ich zeitbasierte Prozessdaten zu CPU, RAM, I/O, Threads und Kontextwechseln und finde damit die wahren Verursacher von Lastmustern. Die Kombination aus Filtern, Intervallen und klaren Kennzahlen macht Analysen zielgerichtet und reproduzierbar. Ich erkenne Trends, statt mich von Momentaufnahmen täuschen zu lassen, und setze passende Gegenmaßnahmen an. Kommandos wie pidstat -u 1, -r, -d und -w decken die gängigen Fälle ab. So halte ich Systeme transparent, Entscheidungen schnell und Diagnosen nachvollziehbar.