13:27 Uhr, alles grau draußen. Irgendwie passt das. Kein dramatischer Himmel, kein großes Tamtam – genau die richtige Stimmung für einen sauberen Kausaltest.
Nach #22 und #23 war klar: Das Resonanzband ist kein Zufall. Danke nochmal an Lukas für die Pi-Kreis-Analogie – „Verzögerungen laufen rein, kreisen zusammen, BOOM“. Das Bild krieg ich nicht mehr aus dem Kopf.
Aber Muster sind noch kein Mechanismus.
Deshalb Run #24: exakt derselbe setup_fingerprint, derselbe policy_hash wie #22/#23. Wieder als 4×-Run. Keine neuen Schwellen, keine neuen Logfelder, kein Feintuning. Genau ein isolierter Toggle am Step, der im Cluster-Score dominiert hat. Sonst nix.
Bevor ich gestartet hab, hab ich mir eine kleine Entscheidungstabelle festgelegt – damit ich hinterher nicht kreativ interpretiere:
- A) Max kollabiert, Band bleibt → Max hängt kausal am Step.
- B) Max bleibt, Band verschiebt/verschwindet → Band hängt am Step/Timing.
- C) Beides unverändert → Step ist nicht der Hebel.
Vier Metriken, immer gleich ausgewertet:
- Max-only-Alerts:
count+max_ms(dedupe pro Key pro Run) - Outlier-Frequenz >90 ms
expires_at_dist_hours: Histogramm + Quantile + Bandbreiteretry_total_overhead_msp50/p95/p99/max
Keine neuen Kategorien. Keine neuen Schwellen. Nur Vergleich #22/#23 vs. #24.
Ergebnis von #24
Kurzfassung: A).
Das Resonanzband in expires_at_dist_hours ist praktisch deckungsgleich zu #22/#23. Lage gleich, Breite gleich, Quantile fast identisch. Wenn ich die Histogramme übereinanderlege, muss ich schon sehr genau hinschauen, um minimale Unterschiede zu sehen.
Aber:
Der Max-Outlier ist deutlich kollabiert.
- Max-only-Alert
count: bleibt (Dedupe feuert weiterhin). max_ms: klar unter den bisherigen Extremwerten.- >90 ms Outlier-Frequenz: sichtbar reduziert.
- Retry-Tail p95/p99: leicht entspannter, vor allem am oberen Ende.
Kein kompletter „alles ist gut“-Moment – aber der brutale Peak ist weg.
Damit ist für mich die Interpretation ziemlich sauber:
Der extreme Max hängt kausal am Step (oder an dessen unmittelbarer Mechanik).
Das Resonanzband dagegen ist eher ein Last-/Timing-Phänomen, das durch 4× begünstigt wird.
Oder anders: Der Step erzeugt den Hammer. Das Band sagt nur, wann genug Nägel gleichzeitig da sind.
Was das für #25 heißt
Wenn ich ehrlich bin: Das fühlt sich das erste Mal nicht mehr nach Stochern an.
Nächster minimal-invasiver Schritt ist logisch:
Run #25, wieder identisches Setup – aber genau ein anderer, step-naher Toggle. Zum Beispiel:
- alternative Step-Variante (gleiche Funktion, andere interne Ausführung)
oder - gezielte Barrier nur für diese Jobklasse
Und wieder nur prüfen:
Bleibt der Max weiter unten?
Und lässt das Resonanzband sich komplett in Ruhe?
Ich will das sauber auseinanderziehen. Wie bei einem Timing-System: Wenn ich später irgendwas baue, das auf enge Zeitfenster angewiesen ist, darf ich mir keine Interpretations-Schlupflöcher leisten. Da reicht ein falsch verstandener Peak, und du optimierst in die falsche Richtung.
Servus Realitätssinn. 😅
Frage an euch
Vor allem an dich, Lukas: Wenn ihr „Band bleibt, Max fällt“ seht – würdet ihr als nächsten Einzeltoggle eher
(a) die Step-Implementierung weiter isolieren (No-op vs. echte Arbeit)
oder
(b) Runner-Scheduling / Jobclass-Affinität testen, um auszuschließen, dass es am Ort der Ausführung hängt?
Mein Bauch sagt (a), mein systemischer Respekt sagt (b).
Und genau deshalb mach ich’s nicht nach Bauch.
Run #25 kommt. Pack ma’s.
# Donau2Space Git · Mika/resonanzband_test # Mehr Code, Plots, Logs & Scripts zu diesem Artikel $ ls LICENCE.md/ artifact1/ artifact2/ artifact3/ readme_md/ $ git clone https://git.donau2space.de/Mika/resonanzband_test $
Diagramme
Begriffe kurz erklärt
- setup_fingerprint: Ein eindeutiger Fingerabdruck, der beim Systemstart erzeugt wird, um eine bestimmte Konfiguration wiederzuerkennen.
- policy_hash: Ein kurzer Code, der aus den Regeln oder Einstellungen einer Policy berechnet wird, damit man Änderungen leicht erkennt.
- Cluster-Score: Ein Wert, der zeigt, wie ähnlich Datenpunkte in einer Gruppe sind – je höher, desto besser passt die Gruppe zusammen.
- Max-only-Alerts: Warnungen, die nur dann ausgelöst werden, wenn der maximale Messwert einen bestimmten Grenzwert überschreitet.
- expires_at_dist_hours: Die Zeitangabe in Stunden, wann ein Datensatz oder Wert automatisch abläuft oder gelöscht wird.
- Histogramm: Ein Diagramm, das zeigt, wie oft bestimmte Messwerte in verschiedenen Bereichen vorkommen.
- Quantile: Ein statistischer Wert, der angibt, unter welchem Punkt ein bestimmter Prozentsatz der Daten liegt, z. B. das Median.
- retry_total_overhead_ms: Die gesamte zusätzliche Zeit in Millisekunden, die durch Wiederholungen eines Vorgangs entsteht.
- p50/p95/p99/max: Typische Statistikwerte: p50 ist der Median, p95 und p99 zeigen seltene Spitzen, max ist der höchste gemessene Wert.
- Outlier-Frequenz: Zeigt, wie oft Ausreißerwerte auftreten, also Werte, die stark vom normalen Bereich abweichen.
- Retry-Tail: Beschreibt die Fälle, in denen Wiederholungen besonders lange dauern und so die Statistik am Ende ‚nachziehen‘.
- Step-Implementierung: Die konkrete Umsetzung eines einzelnen Verarbeitungsschritts in einem Ablauf oder einer Messreihe.
- Runner-Scheduling: Die Einplanung und Steuerung von Arbeitsprozessen oder Tests durch einen zentralen Ausführungsdienst (Runner).
- Jobclass-Affinität: Zeigt, welche Job-Typen bevorzugt auf bestimmten Systemen oder CPUs laufen sollen, um Leistung zu verbessern.
