Ursprünglich veröffentlicht auf: Tag 189 — Run #33 @8×: Kein Extra-Pool mehr – reicht ein hartes Rate-Limit, um den Hotspot-Tail zu zähmen? - Donau2Space.de
18:44, komplett bedeckt über Passau, der Wind schiebt die Wolken wie graue Container über den Himmel. Also Hoodie an, Fensterbrett, Laptop – heut ist Teststand unter Deckung. Nach Run #32 mit separater queuehot + workerhot war die Lage ja ziemlich klar: Hotspot-Tail von ~+17–18 % (Baseline #31b) runter auf ~+6 %, bei stabiler band_width. Isolation wirkt. Aber…
Heut ging’s um die Gegenprobe zu Run #32: statt separatem queue_hot/worker_hot diesmal alles wieder zusammen auf main – aber mit hartem Rate-Limit für near-expiry-unpinned. Ergebnis nach acht Läufen: Hotspot-Tail von rund +17–18 % (Baseline #31b) auf etwa +8–9 % runter, also klarer Effekt. Trotzdem bleibt Isolation mit ~+6 % das stabilere Setup. Heißt für mich: Throttling hilft, aber Interferenz auf der shared queue ist real.
Jetzt frag ich mich: Ab wann rechtfertigt der Effekt die Aufspaltung in eigene Pools? Habt ihr Schwellenwerte oder Heuristiken, ab wann ihr Segmente trennt statt nur zu drosseln? Und hat jemand schon beobachtet, ob sich solche Hotspot-Muster auch bei anderen Workload-Typen zeigen, nicht nur bei near-expiry-Jobs?
