Wie vermisst man ein System?

Der untere Newsticker meines Runtime-Projekts zeigt keine frei erfundene Engine-Metrik, sondern eine aus Linux abgeleitete Auslastungsstatistik. Die Form ist absichtlich knapp:

10-Sek-Avg T1: 31.4% T2: 18.9% T3: 44.2% ...

Damit diese Zeile überhaupt sinnvoll lesbar ist, muss zuerst klar sein, was hier mit T1, T2, T3 gemeint ist.

Abb 1: Der blaue Newsticker unten zeigt die CPU Last

Was ist eine logische CPU?

Unter Linux ist eine logische CPU die Recheneinheit, die der Scheduler einzeln sieht und einzeln belegen kann. Genau diese Einheiten erscheinen in /proc/stat als cpu0, cpu1, cpu2 und so weiter. Die Datei liefert also nicht „Kerne“ im unscharfen Alltagswortlaut, sondern schedulbare Hardware-Einheiten.

Man sollte vier Ebenen auseinanderhalten:

• Sockel / Prozessor: der physische Chip auf dem Mainboard
• Core: ein physischer Rechenkern innerhalb dieses Chips
• Hardware-Thread: eine zusätzliche Ausführungsspur pro Core, typischerweise durch SMT (Simultaneous Multithreading); Intel nennt ein ähnliches Konzept oft Hyper-Threading
• logische CPU: die vom Betriebssystem sichtbare Scheduler-Einheit; praktisch entspricht sie genau so einem Hardware-Thread

Ohne SMT gilt oft: 1 Core = 1 logische CPU.
Mit SMT gilt oft: 1 Core = 2 logische CPUs.

Daneben gibt es noch Programm-Threads. Das sind Threads meines Prozesses. Sie sind eine Software-Struktur. Logische CPUs sind dagegen eine Hardware-/Scheduler-Struktur. Viele Programm-Threads können im Lauf der Zeit auf dieselben logischen CPUs gelegt werden.

Beispiel: AMD Ryzen 7 5700G

Am AMD Ryzen 7 5700G sieht man diese Trennung gut. Dieser Prozessor hat 8 physische Kerne und 16 Threads. Aus Sicht des Betriebssystems stehen also 16 schedulbare Hardware-Threads zur Verfügung.

Für den Ticker heißt das: Auf einem Ryzen 7 5700G sieht Linux typischerweise cpu0 bis cpu15, also 16 logische CPUs. Wenn im Ticker T1 bis T16 auftauchen, dann sind das nicht 16 physische Kerne, sondern 16 vom Scheduler sichtbare Hardware-Threads. Anders gesagt: Bei diesem Prozessor repräsentiert jeder Eintrag Tn einen der 16 CPU-Threads, nicht einen eigenen Core.

Ausgangspunkt der Messung

Die Datenquelle ist /proc/stat. Dort liefert Linux für jede logische CPU kumulative Zähler, also aufsummierte Zeitanteile seit Systemstart. Die cpuN-Zeilen beschreiben, wie viel Zeit diese konkrete CPU in Zuständen wie user, nice, system, idle und weiteren Kategorien verbracht hat.

Der wichtige Punkt: Das sind keine fertigen Prozentwerte, sondern Bestandsgrößen. Ein einzelner Zustand sagt daher noch nichts über aktuelle Last aus. Erst der Vergleich zweier Zustände über ein endliches Intervall macht aus Bestandsgrößen eine lokale Belastungsgröße.

Vom Kernelzähler zur Auslastung

Für jede logische CPU werden in festem Abstand zwei Größen betrachtet:

• total: gesamte aufgelaufene CPU-Zeit
• idle: aufgelaufene Idle-Zeit

Dann werden Differenzen gebildet:

• delta_total = total_neu - total_alt
• delta_idle = idle_neu - idle_alt
• delta_busy = delta_total - delta_idle

Die Intervallauslastung ist dann der normierte Busy-Anteil:

• last_pct = 100 * delta_busy / delta_total

Das ist der entscheidende Schritt: Linux liefert nur kumulative Kernelzähler; die sichtbare Prozentzahl entsteht erst durch Differenzbildung und Normierung.

Warum ein 10-Sekunden-Mittel?

Ein 1-Sekunden-Wert ist korrekt, aber oft zu nervös. Rendering, Scheduling, IRQs und Hintergrundaktivitäten erzeugen kurze Ausschläge, die für einen permanent laufenden Ticker eher Rauschen als Einsicht produzieren. Deshalb wird nicht der letzte Einzelwert direkt angezeigt, sondern pro logischer CPU ein gleitender Mittelwert über die letzten zehn Intervalle gebildet.

Deklarativ gelesen ist die Kette also:

/proc/stat
→ Zustände pro logischer CPU
→ Differenzen über das Messintervall
→ Busy-Anteil
→ normierte Intervallauslastung
→ gleitender 10-Sekunden-Mittelwert
→ Ticker-Darstellung

Oder noch knapper:

Kernel-Zähler
→ delta_total, delta_idle
→ delta_busy
→ last_pct
→ avg_10s
→ T1, T2, T3, ...

Der Ticker zeigt damit keinen Momentanwert im strengen Sinn, sondern einen geglätteten Schätzer der jüngeren Vergangenheit.

Warum die CPU-Sicht und nicht die Thread-Sicht des Programms?

Die Wahl fiel bewusst auf logische CPUs. Prozess-Threads sind nützlich, wenn man Locking, Parallelisierung oder Scheduling innerhalb der Anwendung selbst debuggen will. Die CPU-Sicht beantwortet eine andere Klasse von Fragen: Wird die Last breit verteilt? Gibt es einzelne dauerhaft heißere Hardware-Threads? Ist das System insgesamt eher unterfordert oder nahe an Sättigung? Für einen kompakten Newsticker ist diese Sicht meist die robustere.

Fazit

Der untere Newsticker zeigt also die Auslastung pro logischer CPU, nicht pro Core und nicht pro Programm-Thread. Auf einem AMD Ryzen 7 5700G bedeutet das typischerweise: 8 physische Kerne, 16 Hardware-Threads, also 16 logische CPUs aus Sicht von Linux. Genau diese Einheiten werden aus /proc/stat gelesen, über Differenzen in Intervalllasten übersetzt, über zehn Sekunden geglättet und dann als T1, T2, T3 und so weiter dargestellt.