De scheduler van Go maakt gebruik van een hybride model van coöperatieve en preemptieve multitasking om verhongering zonder OS-interventie te voorkomen. Sinds versie 1.14 injecteert de runtime asynchrone preemptiepunten door SIGURG-signalenen naar threads die goroutines uitvoeren die hun tijdslichaam overschrijden (typisch 10ms). Wanneer de signal-handler een veilige punt detecteert—zoals wanneer de goroutine een functie aanroept of de stack benadert—slaat de scheduler de context op en schakelt over naar een andere uitvoerbare goroutine. Dit mechanisme zorgt ervoor dat zelfs strakke CPU-gebonden lussen zonder functieaanroepen niet oneindig een Processor (P) kunnen monopolizeren.
Ons high-frequency trading platform ondervond catastrofale latentiepieken tijdens marktvolatiliteit, waarbij een enkele analytics goroutine die complexe Monte Carlo-simulaties uitvoerde de orderverwerkingspijplijnen honderden milliseconden bevroor. Het probleem kwam voort uit de goroutine die een strakke wiskundige lus uitvoerde zonder functieaanroepen, waardoor de scheduler vóór Go 1.14 niet kon preëmteren.
We hebben drie verschillende benaderingen geëvalueerd om deze concurrentie op te lossen. De eerste optie hield in dat we handmatig runtime.Gosched()-aanroepen binnen de simulatie-lussen invoegden. Deze aanpak bood onmiddellijke mitigatie, maar introduceerde een aanzienlijke onderhoudsbelasting en vereiste dat ontwikkelaars diepgaande kennis van de scheduler hadden, waardoor er fragiele code ontstond die regressies kon vertonen als deze werd hervormd.
De tweede oplossing stelde voor om de analytics-werkbelasting te isoleren in een aparte microservice met CPU-limieten. Hoewel dit harde isolatie en onafhankelijke schaalbaarheid bood, schond de netwerkserialisatie-overhead en de extra latentie van inter-processcommunicatie onze sub-milisseconde latentie-eisen voor risicoberekeningen.
Uiteindelijk kozen we ervoor om de runtime te upgraden naar Go 1.20 en GOMAXPROCS expliciet af te stemmen op de fysieke CPU-kernen. Deze upgrade zorgde voor asynchrone preemptie via signalen, zodat de scheduler de CPU-gebonden goroutine elke 10ms dwingend kon overdragen zonder codewijzigingen. Post-deployment metrics toonden aan dat de P99 latentie stabiliseerde op 8ms tijdens piekbelasting, waardoor time-out cascades werden geëlimineerd en de eenvoud van de architectuur voor één proces werd behouden.
Waarom veroorzaakt een strakke lus zonder functieaanroepen planningsproblemen in oudere Go-versies, maar niet in nieuwere?
Voor Go 1.14 hielp de scheduler uitsluitend op coöperatieve preemptie, wat betekende dat goroutines vrijwillig alleen op functie-aanroepen, kanaalbewerkingen of mutex-contentie yieldden. Een strakke lus die pure rekenkundige bewerkingen uitvoerde, bereikte nooit een veilig punt, waardoor het effectief zijn Processor (P) monopoliseerde totdat het was voltooid. Modern Go maakt gebruik van asynchrone preemptie door SIGURG-signalenen naar de thread te sturen, waardoor een contextwisseling plaatsvindt bij het volgende veilige punt, ongeacht of er een functie-aanroep plaatsvindt.
Hoe beslist de Go-scheduler welke goroutine als volgende draait wanneer een Processor (P) beschikbaar wordt?
De scheduler implementeert een work-stealing-algoritme dat eerst de lokale uitvoerwachtrij van de huidige P controleert, waarna het probeert de helft van de goroutines van de lokale wachtrij van een andere P te stelen met behulp van een gerandomiseerde beginindex om concurrentie te verminderen. Als de lokale wachtrijen leeg zijn, wordt elke 61 scheduler-tikken de globale uitvoerwachtrij gecontroleerd om verhongering van nieuw aangemaakte goroutines te voorkomen. Deze hiërarchische selectie minimaliseert synchronisatiekosten en waarborgt een load balancing over alle beschikbare Machine (M)-threads.
Wat gebeurt er met de Processor (P) wanneer een goroutine een blokkering-syscall uitvoert, zoals bestand I/O?
Wanneer een goroutine blokkeert op een syscall, koppelt de Go-runtime onmiddellijk de Machine (M)-thread los van zijn P en wijst die P toe aan een nieuwe of inactieve M, zodat andere goroutines op dezelfde OS-thread abstractie kunnen blijven uitvoeren. De oorspronkelijke M gaat de syscall in en wacht op de kernel om de operatie te voltooien; na terugkeer probeert het zijn oorspronkelijke P opnieuw te verwerven of parkeert het zichzelf als de P nu aan een andere thread is gebonden. Deze M:N multiplexing voorkomt dat OS-threads idle blijven tijdens I/O, wat zorgt voor een hoge CPU-utilisatie over duizenden goroutines.