Puls verstehen

Was Füllstand, Inodes, Swap, Last und SMART bedeuten – und wann eine Zahl beunruhigend ist.

Der Reiter Puls eines Geräts zeigt Zahlen, die nur dann helfen, wenn man weiß, was sie messen. Diese Seite erklärt jede davon – ohne Konto, damit auch nachlesen kann, wer NODE64 (noch) nicht benutzt.

Alle Werte kommen vom Agenten auf dem Gerät selbst. NODE64 misst nichts von außen und rät nichts hinzu.

Füllstand #

Wie viel Prozent eines Dateisystems belegt sind. Gemeint ist immer ein Einhängepunkt, nicht eine Festplatte: / und /boot/efi können auf demselben Laufwerk liegen und trotzdem völlig verschieden voll sein.

Ab wann das eng wird, hängt davon ab, was auf dem System läuft:

Eine volle /-Partition legt ein Linux-System praktisch still. Eine volle Datenpartition trifft meist nur einen Dienst.

Inodes #

Ein Dateisystem verwaltet zwei Vorräte, nicht einen: Platz und Inodes. Ein Inode ist der Verwaltungseintrag einer Datei – Rechte, Besitzer, Zeitstempel, wo die Daten liegen. Jede Datei und jedes Verzeichnis braucht genau einen.

Bei der Formatierung von ext4 wird die Zahl der Inodes fest vergeben, üblicherweise einer je 16 KB. Wer viele winzige Dateien anlegt – Sitzungsdateien, Mail-Warteschlangen, Zwischenspeicher, node_modules – verbraucht Inodes viel schneller als Platz.

Der Fall, an dem man das merkt, sieht widersinnig aus:

$ df -h /var
/dev/sda2  100G  41G  59G  41% /var

$ touch /var/test
touch: cannot touch '/var/test': No space left on device

59 Gigabyte frei, und trotzdem kein Speicherplatz. Die Meldung steht hier auf Englisch, weil Server üblicherweise mit LANG=C laufen; auf Deutsch lautet sie „Auf dem Gerät ist kein Speicherplatz mehr verfügbar“. Die Antwort steht in df -i:

$ df -i /var
/dev/sda2  6553600  6553600  0  100% /var

Die Inodes sind aufgebraucht. Deshalb steht der Inode-Anteil in NODE64 neben dem Füllstand und nicht darunter: Es ist eine eigene Frage, und sie wird meist erst gestellt, wenn es zu spät ist.

Abhilfe schafft nur Löschen (oft in /var/spool, /tmp oder alten Zwischenspeichern) – die Inode-Zahl eines bestehenden ext4-Dateisystems lässt sich nicht nachträglich erhöhen.

Warum manche Dateisysteme keine Inode-Zahl zeigen #

btrfs, ZFS und XFS vergeben Inodes dynamisch. Sie haben keine feste Obergrenze und melden dem Betriebssystem deshalb eine Null. NODE64 zeigt dort keinen Wert statt „0 % belegt" – eine erfundene Null wäre eine Entwarnung ohne Grundlage.

vfat, exfat und NTFS kennen das Konzept gar nicht. Auch dort bleibt das Feld leer, mit dem Hinweis warum.

Ein leeres Inode-Feld ist also kein Messfehler, sondern eine Eigenschaft des Dateisystems.

Arbeitsspeicher und Swap #

Arbeitsspeicher (RAM) ist der schnelle Speicher, in dem laufende Programme arbeiten.

Unter Linux ist eine hohe RAM-Auslastung normal und gewollt. Der Kernel benutzt freien Speicher als Zwischenspeicher für Dateien; „frei" bedeutet ungenutzt, und ungenutzter Speicher ist verschwendeter Speicher. NODE64 rechnet deshalb mit dem tatsächlich belegten Anteil, nicht mit dem, was free in der ersten Zeile anzeigt.

Swap ist Auslagerung auf die Festplatte: Wenn der Arbeitsspeicher knapp wird, schiebt der Kernel selten benutzte Seiten dorthin. Das ist um Größenordnungen langsamer.

Ein wenig belegter Swap ist unbedenklich – der Kernel lagert auch dann aus, wenn kein Mangel herrscht, einfach weil eine Seite seit Tagen nicht angefasst wurde. Dauerhaft hoher Swap-Anteil dagegen bedeutet, dass dem System Arbeitsspeicher fehlt: Die Maschine wird spürbar langsam, ohne dass die CPU-Auslastung das erklären würde.

Ist Swap gar nicht eingerichtet, zeigt NODE64 keine Kachel dafür. „0 %" würde eine Reserve suggerieren, die es nicht gibt.

Last und Prozessorauslastung #

Das sind zwei verschiedene Dinge, und sie werden häufig verwechselt.

Prozessorauslastung ist der Anteil der Zeit, in dem die CPU gerechnet hat – ein Prozentwert.

Last (Load Average) ist die durchschnittliche Zahl der Prozesse, die laufen oder auf etwas warten. Unter Linux zählen auch Prozesse mit, die auf die Festplatte oder auf das Netz warten. Deshalb kann die Last hoch sein, während die CPU fast nichts tut – ein klassisches Zeichen für ein überlastetes Laufwerk.

Der entscheidende Punkt: Last muss man durch die Zahl der Kerne teilen. Last 4,0 auf einem Rechner mit vier Kernen heißt „ausgelastet"; dieselbe 4,0 auf einem Kern heißt „viermal überbucht". NODE64 kennt die Kernzahl des Geräts und rechnet die Schwelle entsprechend um – die Alarmschwelle für Last ist deshalb in Prozent angegeben, nicht als absolute Zahl.

Die drei Zahlen von uptime sind Mittelwerte über 1, 5 und 15 Minuten. NODE64 zeichnet die 1-Minuten-Last auf.

Temperatur #

Die Temperatur der Hauptplatine oder des Prozessors, sofern das Gerät Sensoren hat. Virtuelle Maschinen und die meisten Container haben keine – dort fehlt die Kachel.

Übliche Größenordnungen: 30–50 °C im Leerlauf, 60–80 °C unter Last. Moderne Prozessoren drosseln sich ab etwa 95–100 °C selbst, bevor Schaden entsteht. Beunruhigend ist weniger ein einzelner hoher Wert als ein Wert, der über Wochen steigt – das ist meist Staub im Kühler oder ein Lüfter, der nachlässt.

SMART: was die Platte über sich selbst sagt #

SMART ist die Selbstüberwachung von Festplatten und SSDs. Drei Zähler sind die aussagekräftigsten:

Reallocated Sectors – Sektoren, die die Platte als defekt erkannt und durch Reservesektoren ersetzt hat. Ein Wert über null ist noch kein Grund zur Panik; ein Wert, der wächst, schon. Genau deshalb zeigt NODE64 den Verlauf und nicht nur den aktuellen Stand.

Pending Sectors – Sektoren, bei denen das Lesen scheiterte und die noch nicht ersetzt wurden. Das ist der ernstere der beiden Zähler: Hier liegen Daten, die die Platte gerade nicht mehr sicher lesen kann.

Wear Level / Percentage Used (nur SSD) – wie viel der vorgesehenen Schreiblast verbraucht ist. 10 % nach zwei Jahren ist unauffällig; 90 % heißt, dass ein Austausch geplant werden sollte.

Eine wichtige Einschränkung: SMART sagt einen Ausfall nicht zuverlässig voraus. Ein erheblicher Teil der Platten fällt ohne vorherige Auffälligkeit aus. SMART ist ein Frühwarnzeichen, kein Ersatz für Sicherungen.

Die Vorausschätzung #

Neben einem Füllstand steht manchmal ein Satz wie „bei diesem Verlauf in 12 bis 20 Tagen voll". Das ist eine Schätzung aus dem bisherigen Verlauf, keine Vorhersage.

So entsteht sie: NODE64 nimmt die Messpunkte der letzten 30 Tage und bildet die Steigungen aller Punktpaare. Der Median dieser Steigungen ist die geschätzte Zunahme je Tag, das untere und obere Viertel ergeben die Spanne. Dieses Verfahren (nach Theil und Sen) verträgt Ausreißer deutlich besser als eine gewöhnliche Ausgleichsgerade – und Ausreißer sind bei Füllständen der Normalfall, etwa wenn ein Sicherungslauf nachts 20 GB ablegt und sie morgens wieder wegräumt.

Die Schätzung erscheint nur, wenn sie belastbar ist:

• mindestens acht Messpunkte über mindestens zwei Tage,
• und die mittlere Hälfte der Steigungen muss sich über die Richtung einig sein.

Schwankt ein Füllstand, ohne zu steigen, steht dort „kein klarer Trend" statt einer Zahl. Liegt der Zeitpunkt jenseits eines Jahres, steht dort ebenfalls keine Zahl – bis dahin wird die Maschine mehrfach umgebaut, und „in 1400 Tagen voll" klingt nach Wissen, ohne welches zu sein.

Eine Schätzung ersetzt keinen Alarm. Wer benachrichtigt werden will, richtet unter Alarme eine Regel ein – direkt neben jedem Füllstandsbalken führt ein Knopf dorthin.

Was in diesem Wirt läuft #

Bis dahin misst NODE64 den Wirt. Was darin läuft, war bekannt – aber nicht gemessen. Ein Container, der Speicher frisst, ist unsichtbar, bis der Wirt in Not gerät. Dann ist es zu spät für eine ruhige Entscheidung.

Der Puls zeigt jetzt jeden Container und jede virtuelle Maschine mit eigenen Zahlen: Speicher, gedrosselte Prozessorzeit, Prozesse, OOM-Abschüsse und Stillstandszeit. Erkannt werden sechs Arten – Docker, Podman, LXC, Proxmox-LXC, KVM und systemd-nspawn – über dieselben Kernel-Dateien. Kein cAdvisor, kein zusätzlicher Dienst, keine Bibliothek.

Die gedrosselte Zeit ist der eigentliche Fund. Ein Container, der an seiner Prozessorgrenze klebt, ist langsam – und auf dem Wirt sieht man davon nichts, weil dort noch Luft ist.

Auf cgroup v1 fehlt genau eine Zahl: die Stillstandszeit je Container. Der Kernel führt sie dort nicht. Alle anderen Werte sind vollständig, und die Zeile sagt, warum die eine fehlt – statt eine Null zu zeigen, die „niemand musste warten" hiesse.

Ist keine Speichergrenze gesetzt, steht die Menge statt eines Anteils da. „80 % von unbegrenzt" wäre keine Aussage.

Grenzwerte lassen sich je Container anlegen: Speicher nahe der Grenze, anhaltende Drosselung, OOM-Abschuss. Der Betreff ist dabei die halbe Regel – ein Wirt hat zwanzig Container, und gemeint ist fast immer einer.

Acht Zahlen, die erklären, warum es langsam ist #

Last, Prozessor, Speicher, Auslagerung, Füllstände, Temperatur, Laufzeit: alles Zahlen über Verbrauch. Keine davon erklärt einen Server, der bei vierzig Prozent Prozessorlast stillsteht, weil er auf die Platte wartet.

Alle acht sind erst im Verlauf etwas wert. Im Augenblick siehst du sie auch mit top. Drei Tage später – wenn die Frage kommt, warum es letzten Dienstag um drei Uhr langsam war – nur, wenn jemand mitgeschrieben hat.

Fehlt eine davon auf deinem System, steht das da. Auf einer virtuellen Maschine gibt es oft keinen thermischen Drosselzähler; dann bleibt die Zeile leer statt eine Null zu zeigen.