Go, Container und der Linux-Scheduler
Zusammenfassung
River Phillips zeigt, wie nicht erkannte Container-CPU-Limits Go-Garbage-Collection und Anwendungslatenz verschlechtern.
Ideen
- Cgroup-Quoten vergeben CPU-Zeit statt exklusiver Prozessorkerne.
- Die Go-Runtime leitete Parallelität damals aus sichtbaren Host-CPUs ab.
- Zu viele Runtime-Threads verbrauchen ihre Containerquote gleichzeitig.
- Stop-the-World-Phasen warten anschließend auf vom Kernel gedrosselte Threads.
- GOMAXPROCS kann Runtimeparallelität an die tatsächlich erlaubte CPU-Zeit anpassen.
Einsichten
- Zwei Scheduler treffen unabhängig Entscheidungen und erzeugen gemeinsam unerwartete Latenzen.
- Ressourcenlimits wirken erst zuverlässig, wenn Laufzeitumgebungen sie verstehen.
- Durchschnittlicher CPU-Verbrauch verbirgt kurzzeitige Drosselung während koordinierter Phasen.
Fakten
- Der Testcontainer erhielt eine Quote von vier CPUs.
- Angepasstes GOMAXPROCS verkürzte den GC-Zyklus von etwa 2,5 auf unter eine Millisekunde.
- automaxprocs ermittelt passende Werte automatisch aus Cgroup-Informationen.
Empfehlungen
- Gleiche GOMAXPROCS mit Containerquoten ab oder verwende eine automatische Erkennung.
- Analysiere Latenzspitzen zusätzlich mit
runtime/traceundgo tool trace.
Referenzen
Der Link zur Originalquelle öffnet einen neuen Tab.