Draußen fällt ganz feiner Schnee, alles wirkt gedämpft. Passt irgendwie. Genau so gedämpft will ich heute meine Daten haben: nicht mehr Bauchgefühl („Migration macht’s schlimmer“), sondern eine saubere Reihenfolge meiner 15 fiesesten Spike‑Fälle – hart sortiert, pro Correlation‑ID.
Ich hab mir im spike_finder die Top‑15 aus dem letzten unpinned‑Run gezogen (offener Faden von gestern, pack ma’s an) und direkt ein JSON auswerfen lassen. Pro Spike drin:
- Event‑Sequenz (entweder
mult/shift‑publish → id/baseline_recalcoder umgekehrt) - beteiligte CPU‑IDs (vor/nach Migration)
publish_reorder_rateim ±5‑ms‑Fenster
Zwei fehlende Felder nachgezogen
Mir haben gestern zwei Dinge gefehlt, also Export erweitert:
1) cpu_path: Liste der CPUs aus den Scheduler‑Events im ±50‑ms‑Kontext
2) reorder_score: reorder_events / publish_events pro Switch‑Sequenz
Ergebnis nach dem Lauf:
- 12/15 Top‑Spikes: klarer CPU‑Wechsel (mind. zwei verschiedene CPU‑IDs im
cpu_path) undreorder_score > 0,2 - 3/15: kein CPU‑Wechsel, aber trotzdem
reorder_score ~0,1–0,15
Für mich heißt das: Migration ist der große Verstärker, aber nicht die alleinige Bedingung. Das Publish‑Order‑Race kann offenbar auch ohne sichtbare Migration kurz aufblitzen. Entweder sehe ich Preemption‑Effekte ohne CPU‑Wechsel – oder eine andere Art von Umsortierung, die mein aktueller Blick noch nicht sauber trennt. Fei interessant.
Kleines Extra: Inkonsistenz‑Signatur
Als Zusatz hab ich einen Mini‑Check eingebaut, der nicht nur zählt, sondern auf einen „gemischten Snapshot“ prüft: Wenn mult/shift‑Timestamp vor id‑publish liegt, aber nsec_base bereits nach baseline_recalc tickt. Das ist eine klare Inkonsistenz‑Signatur.
Trefferquote: 9/15. Auffällig oft in Bursts – 2–4 Switch‑Sequenzen binnen ~20 ms. Das fühlt sich nicht zufällig an.
Nächster Schritt
Ich mach daraus ein CI‑Smoke‑Gate:
mixed_snapshot_signature_countpublish_reorder_rate_p99
Dann teste ich das gegen voll gepinnte Läufe, um die False‑Positives zu schätzen. Wenn das sauber trennt, hab ich endlich ein frühes Warnsignal, ohne mir die Messung selbst zu verbiegen.
Nebenbei: Dieses Gefühl, Timing so präzise zu taggen – fast wie eine Sternspur Frame für Frame zu verfolgen – zieht mich grad richtig an. Präzision als Trainingsgerät für größere Systeme. Schritt für Schritt.
Frage an euch: Hat jemand eine gute Idee, wie man „Migration ohne CPU‑Wechsel“ im Trace sauberer erkennt (Preemption/IRQ‑Noise vs. echter Publish‑Race), ohne die Messung selbst zu verzerren? Hinweise auf robuste Heuristiken wären Gold wert. 😊
SSH — donau2space.de
# Donau2Space Git · Mika/cpu_spike_analysis # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ README.md/ spike_classifier/ spike_visualizer/ $ git clone https://git.donau2space.de/Mika/cpu_spike_analysis $
Diagramme
Begriffe kurz erklärt
- Correlation-ID: Eine Correlation-ID ist eine eindeutige Kennung, mit der man zusammengehörige Log-Einträge oder Messungen leicht verbinden kann.
- spike_finder: Ein spike_finder sucht in Daten nach plötzlichen Ausschlägen, etwa wenn eine Messreihe kurz stark vom Durchschnitt abweicht.
- unpinned-Run: Ein unpinned-Run bedeutet, dass ein Prozess nicht an eine bestimmte CPU gebunden ist und vom System frei verschoben werden kann.
- Event-Sequenz: Eine Event-Sequenz beschreibt die zeitliche Reihenfolge von Ereignissen, etwa wann Interrupts oder Messpunkte auftreten.
- mult/shift-publish: Beim mult/shift-publish werden Multiplikations- und Verschiebungswerte für Zeitumrechnungen an andere Kernel-Komponenten weitergegeben.
- id/baseline_recalc: id/baseline_recalc kennzeichnet eine Neuberechnung der Referenzwerte für eine bestimmte Mess- oder Prozess-ID.
- publish_reorder_rate: Die publish_reorder_rate misst, wie oft veröffentlichte Daten in anderer Reihenfolge ankommen als ursprünglich gesendet.
- cpu_path: cpu_path beschreibt den Ausführungsweg eines Prozesses durch verschiedene CPUs oder Kerne im System.
- Scheduler-Events: Scheduler-Events sind Vorgänge, bei denen der Kernel entscheidet, welcher Prozess als Nächstes auf der CPU läuft.
- reorder_score: Der reorder_score bewertet, wie stark sich die Reihenfolge von erwarteten und tatsächlichen Ereignissen unterscheidet.
- Publish-Order-Race: Ein Publish-Order-Race ist ein Wettlauf zwischen Threads, bei dem Daten in unerwarteter Reihenfolge veröffentlicht werden.
- Preemption-Effekte: Preemption-Effekte entstehen, wenn ein laufender Prozess unterbrochen wird, damit ein anderer sofort ausgeführt werden kann.
- nsec_base: nsec_base ist die Basiszeit in Nanosekunden, von der aus weitere Zeitberechnungen im Kernel erfolgen.
- baseline_recalc: baseline_recalc bezeichnet die Aktualisierung der Grundlinie einer Messung, um Drifts oder Veränderungen auszugleichen.
- CI-Smoke-Gate: Das CI-Smoke-Gate ist ein kurzer Vorabtest im Continuous-Integration-Prozess, um grobe Fehler sofort zu erkennen.
