Linux procfs für Administratoren: wichtige Dateien im Überblick

Das Linux procfs zeigt den aktuellen Zustand des Kernels über virtuelle Dateien unter /proc. Für die Administration sind vor allem Last, Speicher, Prozesse, Dateideskriptoren und Blockgeräte relevant. Entscheidend ist die Einordnung: Manche Werte sind Momentaufnahmen, andere Zähler seit dem Boot oder gleitende Mittelwerte. Lies deshalb nie nur einen Einzelwert, sondern gleiche ihn mit passenden Signalen und dem Kontext von Host, VM oder Container ab.

procfs verstehen: virtuelle Kernelansicht statt Datenspeicher

Das procfs ist ein virtuelles Dateisystem: Die Einträge unter /proc bilden Datenstrukturen und Zustände des laufenden Linux-Kernels ab. Sie liegen nicht als dauerhaft gespeicherte Inhalte auf einem Datenträger. Beim Lesen erzeugt der Kernel die jeweilige Ansicht aus seinem aktuellen Zustand; nach einem Neustart beginnen etwa viele Zähler erneut. Deshalb ist /proc eine Schnittstelle für Beobachtung und teilweise Steuerung, kein Ort für eigene Dateien oder persistente Konfigurationen.

Für die Administration sind drei Bereiche zu unterscheiden. Globale Statusdateien wie /proc/meminfo, /proc/stat oder /proc/loadavg liefern kernelweite Kennzahlen. Verzeichnisse mit numerischen Namen, etwa /proc/1234, liefern Details zu einem einzelnen Prozess. Unter /proc/sys liegen dagegen Kernelparameter, die abhängig von Berechtigung und Parameter sowohl lesbar als auch schreibbar sein können. Die ähnliche Dateiform darf nicht darüber hinwegtäuschen, dass Statusabfrage und Konfigurationsänderung grundverschiedene Folgen haben.

Welche Pfade und Felder vorhanden sind, ist nicht auf jedem Linux-System identisch. Kernelversion und -konfiguration, Architektur, erkannte Hardware sowie geladene Module beeinflussen die sichtbaren Einträge. Auch Namespaces verändern einzelne Ansichten. Ein procfs, das mit einem PID-Namespace verbunden ist, begrenzt insbesondere die Prozess- und PID-Sicht; daraus folgt jedoch nicht, dass globale Dateien automatisch container- oder cgroup-spezifische Werte zeigen. Skripte sollten Dateien und Felder prüfen, bevor sie deren Inhalt auswerten, statt eine vollständige, überall gleiche procfs-Struktur vorauszusetzen.

Davon abzugrenzen ist sysfs unter /sys: Es stellt vor allem Geräte, Treiber und Hardwareobjekte dar. Für Ressourcenverteilung und Grenzen von Gruppen ist außerdem cgroup2 relevant. procfs bleibt jedoch die unmittelbare Quelle für viele Kernel- und Prozesszustände, die bei einer ersten Diagnose benötigt werden.

Zähler, Momentaufnahmen und Sichtbarkeit richtig einordnen

Der Wert allein erklärt bei procfs selten ein Problem. Zuerst ist sein Zeitbezug zu klären: Einige Angaben sind kumulative Zähler seit Systemstart, andere beschreiben einen aktuellen Zustand, wieder andere bilden gleitende Zeitfenster ab. Ein hoher Zählerstand zeigt zunächst nur, dass sich ein Ereignis seit dem Boot summiert hat. Eine Rate entsteht erst aus zwei Messpunkten: Differenz der Werte geteilt durch das dazwischenliegende Zeitintervall. Das gilt beispielsweise für viele CPU-, Interrupt- und Datenträgerzähler.

Die Datei /proc/uptime liefert die vergangene Betriebsdauer und die aggregierte Idle-Zeit. Sie hilft, Zähler seit dem Start zeitlich einzuordnen, ersetzt aber keine Messreihe. Eine einmalige Abfrage ist eine Momentaufnahme; für belastbare Aussagen über Trends, Spitzen oder wiederkehrende Last braucht es wiederholte Abfragen mit Zeitstempel. Dabei können sich Werte bereits während des Lesens verändern, weil der Kernel weiterarbeitet.

Auch die sichtbaren Daten haben Grenzen. /proc/self verweist stets auf den Prozess, der den Pfad gerade auflöst. Damit ist er für Skripte und interaktive Prüfungen praktisch, ohne eine PID anzunehmen. Der Zugriff auf fremde Prozessverzeichnisse kann jedoch durch Dateirechte, Linux-Capabilities und die procfs-Mount-Option hidepid eingeschränkt sein. Fehlende Einblicke sind in diesem Fall kein defektes procfs, sondern ein Schutz gegen das Auslesen sensibler Prozessinformationen.

Besondere Vorsicht gilt in Containern. Ein an einen PID-Namespace gebundenes procfs zeigt bei prozessbezogenen Pfaden nur die Prozesse dieser Namespace-Sicht. Globale Kerneldateien wie /proc/meminfo, /proc/stat oder /proc/diskstats können dagegen weiterhin Werte des Hosts widerspiegeln und sind nicht automatisch auf das Containerlimit begrenzt. Vor jeder Diagnose ist daher zu klären, ob die Frage Prozesse, globale Kernelwerte oder die tatsächlich zugewiesenen Ressourcen betrifft; Limits und Nutzung eines Containers gehören zusätzlich in die cgroup2-Analyse.

Lesen, konfigurieren und absichern unter /proc/sys

Der Bereich /proc/sys ist die Dateisystemansicht der sysctl-Schnittstelle. Das Lesen eines Werts dient der Diagnostik. Ein Schreibzugriff verändert dagegen unmittelbar das Verhalten des laufenden Kernels und kann Dienste, Ressourcenverbrauch oder Sicherheitsmerkmale beeinflussen. Dass eine Änderung ohne Neustart wirkt, macht sie nicht risikolos und auch nicht automatisch dauerhaft: Persistenz hängt von der gewählten Systemkonfiguration ab.

Die Verzeichnisstruktur erleichtert die erste Einordnung. Unter /proc/sys/fs stehen unter anderem globale Dateisystem- und File-Handle-Parameter. /proc/sys/vm bündelt Einstellungen der Speicherverwaltung, während /proc/sys/net netzwerkbezogene Parameter enthält. Welche Unterverzeichnisse und Schlüssel verfügbar sind, hängt wiederum von Kernelkonfiguration und Funktionen des Systems ab. Ein vorhandener Parameter ist daher kein allgemeines Tuning-Rezept; seine Dokumentation und der konkrete Workload sind maßgeblich.

Ein Gegenbeispiel für scheinbare Optimierung ist drop_caches unter /proc/sys/vm. Die Kernel-Dokumentation ordnet die Funktion Debugging und Tests zu und rät von einem Einsatz außerhalb solcher Zwecke ab, weil das Leeren wiederverwendbarer Caches Leistung kosten kann. Wenig freier Speicher ist für sich genommen kein Grund, Caches zu verwerfen: Der Kernel nutzt RAM bewusst auch für Dateicache.

Vor jeder Änderung sollte eine nachvollziehbare Ursache vorliegen. Sichere zuerst den Ausgangswert, dokumentiere Zweck und erwartete Nebenwirkungen, ändere kontrolliert und beobachte anschließend passende Messwerte sowie Dienstverhalten. Plane den Rückweg vorab und übernimm einen Wert erst nach fachlicher Prüfung in eine dauerhafte Konfiguration. Weiterführende Grundlagen zu Parametern und ihrer kontrollierten Verwaltung behandelt der Beitrag Kernel-Tuning im Linux-Hosting: Sysctl-Parameter im Überblick.

Die wichtigsten procfs-Dateien nach Administrationsaufgabe

Die Auswahl einer procfs-Datei sollte von der Administrationsfrage ausgehen, nicht von einer möglichst vollständigen Verzeichnisliste. Globale Dateien liefern oft kernelweite Werte, Prozesspfade beschreiben einen einzelnen sichtbaren Prozess, und Einträge unter /proc/sys/fs liefern Konfiguration und systemweite Grenzen. Einige Werte sind aktuelle Zustände, andere seit dem Boot kumulierte Zähler oder gleitende Durchschnitte. Diese Unterscheidung entscheidet darüber, ob ein einzelnes Auslesen genügt oder zwei Messpunkte nötig sind.

Die Tabelle ist eine Einstiegshilfe, keine Diagnosekette. Ein auffälliger Wert verlangt stets ein unabhängiges Gegenzeichen: Load mit CPU- und I/O-Daten, Speicherwerte mit Pressure Stall Information und Prozessgrößen mit dem Verhalten des Dienstes. Besonders /proc/diskstats und /proc/stat sind kumulative Zähler; ihre Differenz über ein bekanntes Intervall ist für Raten aussagekräftiger als der absolute Stand. In Containern ist zusätzlich zu prüfen, ob eine Datei globale Kernelwerte oder eine pro cgroup verfügbare Sicht liefert. Die folgenden Abschnitte ordnen die Signale deshalb nach Last, Speicher, Prozessen und I/O ein.

Last, CPU und Speicher: Signale kombiniert bewerten

Bei einer langsamen Anwendung ist /proc/loadavg ein sinnvoller Start, aber kein Urteil über die CPU. Die drei Werte bilden die durchschnittliche Last der letzten 1, 5 und 15 Minuten ab. In die Last gehen nicht nur laufbereite Einheiten im Zustand R ein, sondern auch Tasks im ununterbrechbaren Wartezustand D, etwa bei I/O. Das vierte Feld zeigt die aktuell ausführbaren gegenüber allen existierenden Scheduling-Einheiten. Hoher Load Average kann daher auf CPU-Konkurrenz, blockierte I/O-Zugriffe oder beides hinweisen.

cat /proc/loadavg
grep -E '^(cpu|intr|ctxt|processes)' /proc/stat
cat /proc/meminfo
cat /proc/pressure/memory

Die CPU-Zeilen aus /proc/stat enthalten Zeitanteile seit dem Systemstart in USER_HZ. Um daraus Auslastungsanteile zu ermitteln, müssen zwei Abfragen verglichen werden; ein einzelner Stand zeigt nur angesammelte Zeit. Der Wert iowait ist dabei kein unmittelbares Latenzmaß für Storage: Seine Berechnung hat dokumentierte Grenzen und kann unter bestimmten Umständen sogar sinken. Für eine I/O-Ursache sind daher zusätzlich Gerätewerte und I/O-PSI sinnvoll.

Auch ein niedriger Wert bei MemFree beweist noch keine RAM-Not. Linux nutzt unbenutzten Arbeitsspeicher gezielt für Cache. MemAvailable schätzt, wie viel Speicher neue Anwendungen voraussichtlich ohne Swapping erhalten können, und ist für die erste Einordnung meist hilfreicher. Erst wenn MemAvailable knapp wird und gleichzeitig Speicher-Stalls auftreten, verdichtet sich der Hinweis auf Speicherdruck. In einem Container können diese globalen Speicherwerte allerdings vom Host stammen; für zugesicherte oder begrenzte Ressourcen ist die cgroup2-Sicht zusätzlich maßgeblich.

Die Dateien unter /proc/pressure ergänzen diese Sicht. Bei memory und io bedeutet some, dass wenigstens einige Tasks während eines Anteils des Zeitfensters nicht weiterkamen; full steht dort für einen Zustand, in dem alle nicht-idlen Tasks gleichzeitig blockiert waren. Die Angaben avg10, avg60 und avg300 beziehen sich auf 10, 60 und 300 Sekunden, total ist ein kumulierter Stall-Zähler. Für CPU ist systemweites full semantisch nicht definiert und wird seit Linux 5.13 aus Kompatibilitätsgründen als null ausgegeben; als Diagnosewert ist es auf Systemebene daher nicht zu interpretieren. CPU-, memory- und io-PSI beantworten unterschiedliche Fragen und sollten nicht gegeneinander ausgetauscht werden.

Reagiert ein Dienst bei geringem MemFree langsam, prüfst du zunächst MemAvailable und /proc/pressure/memory. Sind beide unauffällig, spricht das gegen akuten systemweiten Speicherdruck. Anschließend kann /proc/<PID>/status zeigen, ob der betroffene Prozess etwa eine hohe VmRSS-Näherung, viele Threads oder einen auffälligen State aufweist. Diese Kombination trennt eine Cache-lastige, aber normale Speichernutzung von einem Problem, das weitere Prozessanalyse verlangt.

Prozesse, Dateideskriptoren und Datenträger-I/O untersuchen

Für eine sichere Übung mit einem garantiert vorhandenen Prozess steht $$ für die PID der aktuellen Shell. Die status-Datei ist menschenlesbarer als die feldorientierte stat-Datei. Name identifiziert den Prozess, State seinen Zustand, PPid den Elternprozess und Threads die Thread-Anzahl. VmRSS ist eine schnelle Näherung für residenten Speicher, deren RSS-Buchführung skalierbar und asynchron erfolgt und deshalb ungenau sein kann; VmSize beschreibt dagegen virtuellen Adressraum. FDSize beschreibt die Größe der Deskriptortabelle, nicht zwingend die Zahl aktuell offener Einträge. Freiwillige und unfreiwillige Kontextwechsel können bei der Einordnung von Scheduling-Verhalten helfen, sind allein aber kein Fehlerbeweis.

cat /proc/$$/status
ls -l /proc/$$/fd

Das fd-Verzeichnis enthält symbolische Links auf offene Dateien, Pipes, Geräte oder Sockets. Es hilft etwa, einen Prozess zu finden, der eine gelöschte Logdatei weiterhin geöffnet hält. Eine große Zahl offener Dateideskriptoren ist jedoch bei Proxys, Datenbanken oder ereignisorientierten Servern durchaus erwartbar. Für gefilterte Ansichten und die Zuordnung über Prozesse hinweg ist lsof zur Analyse offener Dateien einsetzen eine passende Ergänzung. Kommandozeilen aus cmdline können vertrauliche Argumente preisgeben; environ ist wegen möglicher Zugangsdaten oder Tokens noch sensibler und keine Routineabfrage.

maps listet virtuelle Speicherbereiche mit Berechtigungen, Offset, Gerät, Inode und gegebenenfalls Pfad. smaps ergänzt je Mapping detaillierte Speicherwerte und liefert gegenüber RSS-Angaben eine genauere, aber aufwendigere Momentaufnahme. Beide Dateien sind für vertiefte Speicheranalysen gedacht: Ihre Ausgabe kann groß sein, und die Interpretation einzelner Mappings erfordert Kontext. Für den ersten Blick sind status und die systemweiten Speicher- und PSI-Dateien meist effizienter.

Bei hohem Load und geringer CPU-Auslastung erweitert /proc/diskstats die Diagnose um die Geräteebene. Die Datei führt pro Blockgerät kumulative I/O-Statistiken. Um Aktivität als Rate zu bewerten, müssen zwei Zeitpunkte verglichen werden. Dabei sind physische Laufwerke, Partitionen und virtuelle oder Device-Mapper-Geräte sauber zu unterscheiden; Zähler verschiedener Ebenen dürfen nicht blind addiert werden. Ein offener Dateideskriptor eines Prozesses lässt sich dabei nicht unmittelbar einem diskstats-Gerätezähler zuordnen: Dateisystem, Cache und Mapping-Schichten liegen dazwischen. Zusammen mit /proc/pressure/io lässt sich dennoch prüfen, ob beobachtbare I/O-Stalls und Geräteaktivität zeitlich zusammenfallen.

procfs im Betrieb: Abfragen, Monitoring und Datenschutz

Für wiederholbare Betriebsdiagnosen behandelst du procfs-Abfragen als Messpunkte: Du notierst Zeitstempel, Systemkontext und die konkrete Abfrage. Viele Werte sind seit dem Start kumulierte Zähler; erst die Differenz zweier Werte geteilt durch das Zeitintervall ergibt eine Rate. Das gilt etwa für Zähler aus /proc/diskstats. Eine Einzelabfrage kann daher Aktivität belegen, aber weder Durchsatz noch eine dauerhafte Verschlechterung zuverlässig quantifizieren.

Ein Monitoring-System sollte in festen Intervallen unter anderem Speicherwerte aus /proc/meminfo, Gerätewerte aus /proc/diskstats, Prozess- und Systemzustände sowie bei verfügbarer Kernelunterstützung Drucksignale erfassen. Es muss Rohwerte in passende Einheiten umrechnen, bei Zählern Differenzen bilden und Historien speichern. In Containern darf es globale procfs-Werte nicht mit den Ressourcenlimits der Workload gleichsetzen: Prozesspfade können auf den PID-Namespace begrenzt sein, während Speicher- oder Gerätewerte teilweise den Host abbilden. Für Limits und Auslastung einer Gruppe sind ergänzende cgroup2-Metriken nötig. Erst zeitliche Verläufe erlauben belastbare Schwellenwerte: Ein hoher Wert kann normal sein, wenn er zum erwarteten Lastfenster passt; ein plötzlicher Anstieg gegenüber der eigenen Baseline ist oft relevanter. Die verfügbaren procfs-Einträge hängen vom laufenden Kernel und seiner Konfiguration ab.

Direkte Dateien und Werkzeuge ergänzen sich. ps, top oder htop eignen sich für die interaktive Prozesssicht; free, vmstat, iostat, pidstat, ss und sar bereiten je nach Installation Daten für bestimmte Fragen auf. procfs bleibt sinnvoll, wenn du die Kernelquelle direkt prüfen oder ein kleines, nachvollziehbares Skript bauen möchtest. Für Alarmierung und Kapazitätsplanung sind Zeitreihendaten meist die passendere Ebene.

Auch bei rein lesenden Abfragen gelten Sichtbarkeitsgrenzen. Zugriffsrechte, Mount-Optionen und PID-Namespaces können Prozessdaten ausblenden oder auf eine Containeransicht begrenzen. Umgekehrt bedeutet eine eigene /proc-Einhängung nicht, dass jede globale Kerneldatei nur Daten des Containers enthält. Ein fehlender Prozesseintrag oder ein unerwartet hoher globaler Wert ist deshalb zunächst ein Hinweis darauf, Ausführungsumgebung, Mount-Optionen und cgroup-Kontext zu klären.

Diagnosepfade für langsame Dienste und Ressourcenengpässe

Troubleshooting beginnt mit einem Symptom, nicht mit einem vermeintlich schuldigen Einzelwert. Prüfe danach mindestens ein unabhängiges Signal und halte fest, ob die Beobachtung den Host, eine virtuelle Maschine oder einen Container betrifft. So vermeidest du beispielsweise, einen hohen Load vorschnell als CPU-Problem oder eine große Zahl offener Deskriptoren vorschnell als Leck zu bewerten. Die folgenden Pfade sind lesende Erstdiagnosen und ersetzen keine anwendungsbezogenen Logs.

Bei hoher Load Average prüfst du zunächst, ob ausführbare oder wartende Aufgaben die Zahl treiben. Die Load-Angaben bilden Durchschnittswerte über ein, fünf und 15 Minuten ab und berücksichtigen sowohl R- als auch D-Zustände. Vergleiche deshalb CPU-Zeitfelder nur mit Vorsicht mit I/O-Druck und Geräteaktivität. Insbesondere iowait darf nicht isoliert als Speicherlatenz gelesen werden.

Bei einer langsamen Anwendung und kleinem MemFree ist MemAvailable der bessere erste Kontextwert. Ergänze Speicher-PSI und den Status des betroffenen Prozesses, etwa dessen VmRSS, Threadzahl und Zustand. PSI unterscheidet bei Speicher und I/O zwischen some für teilweise blockierte Tasks und full für vollständige Blockierung nicht-idler Tasks. Fehlen PSI-Dateien, kann dies an Kernelkonfiguration oder Umgebung liegen; es widerlegt keinen Engpass.

Für Datei- und Prozessdiagnosen können Rechte und PID-Namespaces die Aussagekraft einschränken. In Containern beschreibt /proc häufig nur die zugeordnete Prozesswelt. Bei verweigertem Zugriff oder unvollständigen Verzeichnissen prüfst du daher Nutzerrechte, procfs-Mount-Optionen und den Namespace-Kontext, bevor du aus der Abwesenheit von Daten eine technische Schlussfolgerung ziehst.

Typische Fehlannahmen korrigieren und passende Werkzeuge wählen

Vier Kurzschlüsse führen in der Linux-Administration häufig zu falschen Maßnahmen. Wenig MemFree bedeutet nicht automatisch RAM-Not, weil der Kernel Speicher unter anderem als Cache nutzt; für neue Anwendungen ist MemAvailable die aussagekräftigere Schätzung. Hoher Load beweist keine CPU-Sättigung, da auch ununterbrechbar wartende Aufgaben einfließen. Ein hoher iowait-Anteil misst keine unmittelbare Latenz eines Datenträgers. Und procfs ist nicht überall identisch: Kernelversion, Konfiguration, Hardware, Module und Namespaces beeinflussen Dateien und Felder.

Wähle die Methode nach der Frage. Für eine punktuelle Ursachenanalyse liefert procfs unmittelbare Rohdaten des laufenden Kernels. Für eine schnelle, menschenlesbare Übersicht sind spezialisierte Kommandozeilenwerkzeuge meist effizienter. Wenn Trends, Alarmierung oder Kapazitätsentscheidungen zählen, benötigst du ein Monitoring, das Messpunkte zeitlich einordnet, Zählerdifferenzen berechnet und historische Vergleichswerte vorhält. Bei Ressourcenlimits einzelner Dienste oder Container ergänzt eine Analyse auf cgroup-Ebene die globale Hostansicht; PSI kann bei passender Konfiguration auch pro cgroup verfügbar sein.

Besondere Zurückhaltung gilt für /proc/sys. Das Lesen eines Parameters ist Diagnostik, das Schreiben verändert aktives Kernelverhalten. Ändere einen Wert nur, wenn die Ursache verstanden ist, der Ausgangswert dokumentiert wurde, Auswirkungen beobachtbar sind und ein Rückweg feststeht. Die Verzeichnisse fs, vm und net ordnen Parameter thematisch, liefern aber keine universellen Tuningvorgaben.

Das Beispiel drop_caches zeigt den Unterschied zwischen Eingriff und Optimierung: Die Kernel-Dokumentation beschreibt die Schnittstelle als nicht destruktiv, warnt jedoch vor Leistungsproblemen und empfiehlt sie nicht als reguläre Betriebsmaßnahme außerhalb von Test- oder Debug-Szenarien. Eine konservative Regel lautet daher: Erst messen, dann eine begründete Änderung begrenzt vornehmen, Wirkung und Nebenwirkungen beobachten und die Entscheidung dokumentieren.