Der Scheduler von Go verwendet ein hybrides, kooperatives und präemptives Multitasking-Modell, um Hunger ohne OS-Intervention zu verhindern. Seit Version 1.14 injiziert die Laufzeit asynchrone Präemption-Punkte, indem sie SIGURG-Signale an Threads sendet, die Goroutines ausführen, die ihre Zeitscheibe (typischerweise 10 ms) überschreiten. Wenn der Signal-Handler einen sicheren Punkt erkennt, wie z. B. wenn die Goroutine bereit ist, eine Funktion aufzurufen oder auf den Stack zuzugreifen, speichert der Scheduler den Kontext und wechselt zu einer anderen ausführbaren Goroutine. Dieser Mechanismus stellt sicher, dass sogar enge CPU-gebundene Schleifen ohne Funktionsaufrufe nicht unbegrenzt einen Prozessor (P) monopolisiert.
Unsere Hochfrequenzhandelsplattform erlebte katastrophale Latenzspitzen während der Marktschwankungen, bei denen eine einzelne Analyse-Goroutine, die komplexe Monte-Carlo-Simulationen durchführte, die Auftragsverarbeitungs-Pipelines für Hunderte von Millisekunden einfrierte. Das Problem entstand daraus, dass die Goroutine eine enge mathematische Schleife ohne Funktionsaufrufe ausführte, wodurch der Scheduler sie vor Go 1.14 nicht präempten konnte.
Wir haben drei verschiedene Ansätze evaluiert, um diesen Konflikt zu lösen. Die erste Option bestand darin, manuell Aufrufe von runtime.Gosched() innerhalb der Simulationsschleifen einzufügen. Dieser Ansatz bot eine sofortige Milderung, verursachte jedoch erheblichen Wartungsaufwand und erforderte von den Entwicklern tiefes Wissen über den Scheduler, was zu fragilen Code führte, der bei einer Umgestaltung zurückfallen könnte.
Die zweite Lösung schlug vor, die Analyselast in einen separaten Mikrodienst mit CPU-Limits zu isolieren. Während dies eine harte Isolation und unabhängige Skalierung bot, verletzte die Übertragungskosten im Netzwerk und die zusätzliche Latenz der interprozessualen Kommunikation unsere Anforderungen an eine Sub-Millisekundenlatenz für Risikoanalysen.
Letztendlich entschieden wir uns dafür, die Laufzeit auf Go 1.20 zu aktualisieren und GOMAXPROCS explizit an die physischen CPU-Kerne anzupassen. Dieses Upgrade ermöglichte asynchrone Präemption über Signale, wodurch der Scheduler die CPU-gebundene Goroutine alle 10 ms zwangsweise abgeben konnte, ohne Codeänderungen vornehmen zu müssen. Die Metriken nach der Bereitstellung zeigten, dass die P99-Latenz während der Spitzenlast auf 8 ms stabil war, wodurch Zeitüberschreitungen ausgeschlossen und die Einfachheit der Architektur eines einzelnen Prozesses bewahrt wurde.
Warum verursacht eine enge Schleife ohne Funktionsaufrufe in älteren Go-Versionen Planungsprobleme, aber nicht in neueren?
Vor Go 1.14 verließ sich der Scheduler ausschließlich auf kooperative Präemption, was bedeutete, dass Goroutines nur bei Funktionsaufrufen, Kanaloperationen oder Mutex-Kontention freiwillig aufgaben. Eine enge Schleife, die reine arithmetische Operationen durchführte, erreichte nie einen sicheren Punkt und monopolierte effektiv ihren Prozessor (P) bis zum Abschluss. Modernes Go nutzt asynchrone Präemption, indem es SIGURG-Signale an den Thread sendet, die einen Kontextwechsel beim nächsten sicheren Punkt auslösen, unabhängig davon, ob ein Funktionsaufruf erfolgt oder nicht.
Wie entscheidet der Go-Scheduler, welche Goroutine als nächstes ausgeführt wird, wenn ein Prozessor (P) verfügbar wird?
Der Scheduler implementiert einen Work-Stealing-Algorithmus, der zunächst die lokale Ausführungswarteschlange des aktuellen P überprüft, dann versucht, die Hälfte der Goroutines aus der lokalen Warteschlange eines anderen P mithilfe eines randomisierten Startindexes zu stehlen, um Konkurrenz zu reduzieren. Wenn die lokalen Warteschlangen leer sind, überprüft er alle 61 Scheduler-Ticks die globale Ausführungswarteschlange, um das Verhungern neu erstellter Goroutines zu verhindern. Diese hierarchische Auswahl minimiert die Synchronisierungskosten und sorgt gleichzeitig für eine Lastenverteilung über alle verfügbaren Maschine (M)-Threads.
Was passiert mit dem Prozessor (P), wenn eine Goroutine einen blockierenden Syscall wie Datei-I/O ausführt?
Wenn eine Goroutine bei einem Syscall blockiert, trennt die Go-Laufzeit sofort den Maschine (M)-Thread von seinem P und weist diesem P einen neuen oder Leerlauf M zu, sodass andere Goroutines weiterhin auf demselben OS-Thread-Abstraktion ausgeführt werden können. Der ursprüngliche M tritt in den Syscall ein und wartet, bis der Kernel den Vorgang abgeschlossen hat; nach der Rückkehr versucht er, seinen ursprünglichen P wieder zu erwerben oder parkt sich selbst, wenn der P jetzt an einen anderen Thread gebunden ist. Diese M:N-Multiplexierung verhindert, dass OS-Threads während I/O im Leerlauf sind und gewährleistet eine hohe CPU-Auslastung über Tausende von Goroutines.