Heilige Drei Könige heute – hier in Bayern sogar mit Feiertag. Genau ein Jahr ist’s jetzt her, seit dem letzten Epiphanias, und irgendwie passt das: nix glauben, alles prüfen. Draußen ist’s bedeckt und kalt, die Donau schaut eher nach Blei als nach Wasser aus. Ich sitz am Fensterbrett mit Laptop und Handschuhen, fei kein Witz – nach zwei Minuten ohne sind die Finger taub.
Der Plan für heute war klar: Ich will nicht mehr annehmen, dass der lange Tail in der VM „eh nur Virtualisierung“ ist. Ich will messen und danach zumindest einen Faktor sauber bestätigen oder ausschließen. Offener Faden von gestern: TSC stable/unstable und vCPU‑Migration als möglicher Verstärker für das Mixed‑Snapshot‑Fenster.
Drei Könige, drei Konfigurationen
Als kleines Ritual hab ich mir drei Läufe gegönnt, jeweils ~200 clocksource_switch()‑Ereignisse:
- Host (Baseline)
- VM unpinned
- VM pinned (vCPU fest auf pCPU,
nohz_fullaus)
Wie schon zuvor logge ich pro Switch (Δ = tms − tid). Neu dazugekommen in trace_agg.py:
- ein Flag, ob der Kernel den TSC als stable oder unstable meldet (aus dmesg/trace gezogen)
- ein Label, ob der Run pinned ist oder nicht
Kein Hexenwerk, eher Aufräumen – aber genau das bringt gerade am meisten.
Ergebnis (kurz und nüchtern)
- Host: P95 bleibt im µs‑Bereich, die Verteilung ist schmal. Genau so, wie man’s erwartet.
- VM unpinned: P95 wächst deutlich, der Tail wird richtig lang.
- VM pinned: P95 fällt spürbar ab, der Tail schrumpft sichtbar – aber: immer noch breiter als auf dem Host.
Damit ist für mich klar: Virtualisierung allein erklärt’s nicht. vCPU‑Migration wirkt als messbarer Verstärker für das Mixed‑Snapshot‑Fenster, ist aber nicht dessen Ursprung. Das fühlt sich gut an, weil es ein echter Fortschritt ist: ein Faktor weniger im Nebel.
Was heißt das jetzt?
Das Thema trägt noch. Ich kann jetzt einen Einfluss quantifizieren und das Setup wird CI‑näher. Nächster logischer Schritt:
Den gleichen 3er‑Vergleich nochmal fahren, aber mit dem geplanten BPF‑Timestamp direkt beim Schreiben von mult/shift (inkl. base_raw / nsec_base). Dann seh ich hoffentlich, ob Pinning das Publish‑Order‑Fenster selbst verkleinert – oder nur die Sichtbarkeit über Δ glättet. Daraus soll am Ende eine saubere Schwelle für einen CI‑Smoke‑P95‑Alarm fallen.
Eine Frage in die Runde, bevor ich weiterzieh: Kennt jemand einen sauberen, programmgesteuerten Weg, das tsc stable/unstable‑Signal pro Boot einzusammeln (nicht nur aus dmesg), sodass es wirklich CI‑tauglich ist? Das wär der letzte fehlende Baustein.
Jetzt speicher ich die drei Histogramme ab (Host vs. VM unpinned vs. VM pinned) und pack sie gleich daneben. Pack ma’s – fühlt sich an, als wär ich wieder einen kleinen Schritt näher dran, Dinge nicht nur zu beobachten, sondern wirklich zu verstehen. 🚀
Diagramme
Begriffe kurz erklärt
- TSC stable/unstable: Zeigt an, ob der Zeitmesser in der CPU (Time Stamp Counter) gleichmäßig läuft oder durch Energiesparen und Taktschwankungen unzuverlässig wird.
- vCPU‑Migration: Wenn eine virtuelle CPU in einer VM von einem physischen Prozessor-Kern auf einen anderen verschoben wird.
- Mixed‑Snapshot‑Fenster: Ein Zeitraum, in dem Messwerte aus alter und neuer Datenquelle überlappen, z. B. beim Umschalten von Zeitsignalen.
- clocksource_switch(): Kernel‑Funktion, die die verwendete Zeitquelle des Systems wechselt, etwa von TSC auf HPET oder umgekehrt.
- nohz_full: Ein Linux‑Kernel‑Modus, der überflüssige Timer‑Interrupts für bestimmte CPU‑Kerne abschaltet, um genaue Messungen oder Echtzeit‑Tasks zu ermöglichen.
- trace_agg.py: Ein Python‑Skript, das gesammelte Tracing‑Daten zusammenfasst und statistisch auswertet.
- pCPU: Physischer Prozessor‑Kern, auf dem virtuelle CPUs (vCPUs) tatsächlich laufen.
- BPF‑Timestamp: Zeitstempel, der von einem BPF‑Programm im Kernel erfasst wird, z. B. um Ereignisse exakt zu messen.
- base_raw: Unverarbeiteter Grundwert einer Zeitmessung oder Statistik, bevor Umrechnungen oder Korrekturen angewendet werden.
- nsec_base: Grundwert der Zeitbasis in Nanosekunden, auf dem weitere Berechnungen aufbauen.
- Publish‑Order‑Fenster: Kleines Zeitintervall, in dem Daten veröffentlicht werden, damit die Reihenfolge synchron bleibt.
- CI‑Smoke‑P95‑Alarm: Warnung im Continuous‑Integration‑Test, wenn 95 % der Messwerte (P95) schlechter sind als ein festgelegter Grenzwert.
