Vor Go 1.3 verwendete die Laufzeit segmentierte Stapel, die an den Grenzen von Funktionsaufrufen in verknüpfte Teile aufgeteilt wurden. Dieses Design führte zu erheblichen Leistungsabfällen beim "Hot Split", wenn die Stapelgrenze während enger Schleifen häufig überschritten wurde. Go 1.3 ersetzte dies durch zusammenhängende Stapel, die während des Wachstums in größere, zusammenhängende Bereiche kopiert werden. Frühere Implementierungen von zusammenhängenden Stapeln gaben jedoch niemals Speicher an den Heap zurück, was zu einem dauerhaften Wachstum des RSS für Goroutinen führte, die vorübergehend tiefe Aufrufstapel während der Initialisierung oder Batchverarbeitung benötigten. Go 1.5 führte das automatische Verkleinern des Stapels ein, um ungenutzten Speicher des Stapels während der Garbage-Collection-Zyklen zurückzugewinnen und schloss den Lebenszyklus des Speichermanagements für Goroutine-Stapel ab.
Ohne einen Verkleinerungsmechanismus würde eine Goroutine, die vorübergehend in eine tiefe Rekursion eintritt (z. B. beim Verarbeiten eines tief verschachtelten JSON-Dokuments oder beim Durchlaufen eines komplexen Abhängigkeitsbaums), ihre maximale Stapelzuweisung unbegrenzt behalten, selbst nachdem sie in eine im Leerlauf befindliche Ereignisschleife zurückgekehrt ist. Dies führt zu einem Speicherüberlauf in langlaufenden Anwendungen, insbesondere in solchen, die Arbeitsgruppen verwenden, in denen Goroutinen zwischen Aufgaben mit großem Stapel und Leerlaufzuständen wechseln. Die Herausforderung besteht darin, sicher zu identifizieren, wann ein Stapel tatsächlich unterutilisiert ist und aktive Frames ohne Korruption laufender Berechnungen, stapelzugeordneter Zeiger oder Verletzung der ABI-Anforderungen für Aufrufkonventionen an einen kleineren Speicherbereich verschoben werden können.
Die Go-Laufzeit verkleinert Stapel während der GC-Markierungsphase, wenn Root-Sets gescannt werden. Sie untersucht die Stapelnutzung jeder Goroutine; wenn der Höchststand des genutzten Anteils unter ein Viertel (25%) der aktuell zugewiesenen Stapelgröße fällt, weist die Laufzeit einen neuen Stapel zu, der die Hälfte der Größe des aktuellen hat (aber niemals kleiner als die minimale 2KB). Die Laufzeit stoppt dann die Zielgoroutine asynchron an einem sicheren Punkt, kopiert die aktiven Stapelrahmen in den neuen, kleineren Bereich, verwendet vom Compiler generierte Zeigerkarten, um alle inneren Zeiger, die auf Stapeladressen verweisen, zu aktualisieren, und gibt den alten Stapelspeicher an den mheap-Allocator der Laufzeit zurück.
Wir betrieben einen hochdurchsatzfähigen Logverarbeitungsdienst, bei dem jede Goroutine das Parsen von potenziell tief verschachtelten JSON-Nutzlasten handhabte (bis zu 10.000 Ebenen tief während von ungültigen Eingaben verursachten Angriffen). Nach der Verarbeitung kehrten diese Goroutinen zu einem sync.Pool zurück, um auf neue Verbindungen zu warten. Wir beobachteten, dass der RSS-Speicher des Dienstes linear mit der Anzahl der gepoolten Goroutinen wuchs, ohne Speicher auch während Leerlaufzeiten freizugeben, was schließlich OOM-Tötungen in Containern mit 4GB-Limits auslöste, obwohl der tatsächliche Arbeitsdatensatz nur 200MB betrug.
Wir überlegten, gepoolte Goroutinen nach einer bestimmten Anzahl verarbeiteter Anforderungen gewaltsam zu beenden und frische Ersatzteile zu erzeugen. Dies würde garantieren, dass der Stapelspeicher freigegeben wird, da neue Goroutinen mit minimalen 2KB-Stapeln beginnen. Dieser Ansatz führte jedoch zu erheblichen CPU-Überkopfkosten durch ständige Erstellung und Zerstörung von Goroutinen, störte die TCP-Verbindungs-Pooling-Optimierungen und führte zu höheren Latenzen aufgrund von Cache-Kaltstarts.
Die Implementierung einer harten Begrenzung des Stapelwachstums über debug.SetMaxStack würde übermäßige Zuweisungen während der tiefen Rekursionsevents verhindern. Während dies vor OOM schützte, führte es zu Panik bei legitimen, aber tiefen Parsing-Aufgaben mit runtime: goroutine stack exceeds 1000000000-byte limit. Dies führte zu verlorenen Kundendaten und Servicefehlern, die unsere Zuverlässigkeits-SLAs verletzten, was es für die Produktion inakzeptabel machte.
Wir bewerteten, ob wir alle 30 Sekunden regelmäßig runtime.GC() aufrufen sollten, gefolgt von debug.FreeOSMemory(), um das Scannen und Verkleinern des Stapels zu erzwingen. Dies reduzierte erfolgreich den RSS, führte jedoch zu Stop-the-World-Pausen von 5-10 ms bei jedem Aufruf, was unsere p99-Latenzanforderungen von <2ms für die API-Ebene verletzte und die CPU-Auslastung um 15% erhöhte, da vollständige Sammlungen gezwungen wurden.
Letztendlich verließen wir uns auf den nativen Mechanismus von Go zum Verkleinern des Stapels, indem wir sicherstellten, dass wir Go 1.20+ ausführen und GOGC so einstellen, dass häufigere Garbage Collections ausgelöst wurden (Einstellung auf 50 statt 100). Dies erhöhte die Häufigkeit der Verkleinerungsmöglichkeiten des Stapels ohne manuelles Eingreifen. Wir restrukturierten auch den Parser, um einen iterativen Ansatz mit einem explizit heap-zugewiesenen Stapel für die Verfolgung von Pfaden zu verwenden, wodurch die maximale Rekursionstiefe von 10.000 auf 100 reduziert wurde. Die Kombination ermöglichte es, dass die natürliche Verkleinerung häufig genug auftrat, um den Speicher begrenzt zu halten.
Der RSS des Dienstes stabilisierte sich unter Last bei etwa 800MB, nach einem vorherigen Maximum von 3,8GB. Stapelprofile der Goroutinen zeigten, dass 95% der gepoolten Arbeiter zwischen den Anforderungen die minimale Stapelgröße von 2KB aufrechterhielten, mit Spitzen, die nur während des aktiven Parsings auftraten. Die OOM-Tötungen hörten vollständig auf und die p99-Latenz blieb unter 1,5 ms, da wir manuelle GC-Pausen und Goroutine-Fluktuationen vermieden.
Tritt stapelverkleinern sofort ein, wenn eine Funktion zurückkehrt und der Stapelzeiger sinkt?
Nein, die Laufzeit überwacht keine Abnahmen des Stapelzeigers in Echtzeit, um sofortige Deallokationen auszulösen. Das Verkleinern erfolgt ausschließlich während der Garbage-Collection-Markierungsphase, wenn der Scheduler alle Goroutine-Stapel scannt. Die Laufzeit überprüft den Höchststand der Stapelnutzung seit der letzten GC. Wenn dieser Höchststand unter 25% der aktuellen physischen Zuweisung liegt, wird erst dann die Verkleinerungslogik ausgeführt. Diese verzögerte Bewertung amortisiert die Kosten des Kopierens von Stapeln über alle Goroutinen während einer Zeit, in der die Welt ohnehin für die Markierung pausiert ist, obwohl das tatsächliche Kopieren das Anhalten der einzelnen Goroutine erfordert.
Wie hoch ist das genaue Verhältnis zur Verkleinerung und die Mindestgröße, und gibt die Laufzeit Speicher jemals an das Betriebssystem zurück?
Wenn ein Stapel für die Verkleinerung qualifiziert ist, weist die Laufzeit einen neuen Stapel mit der halben Größe des aktuellen zu. Diese geometrische Reduzierung verhindert ein Schwingen, bei dem eine Goroutine, die leicht über und unter einer Schwelle schwankt, ständig wachsen und schrumpfen würde. Die neue Größe ist durch die minimale Stapelgröße der Plattform begrenzt, typischerweise 2KB auf 64-Bit-Systemen. Der Speicher des alten Stapels wird an den mheap der Laufzeit zurückgegeben, nicht direkt an das Betriebssystem. Das Betriebssystem fordert diesen physischen Speicher nur dann zurück, wenn der Sammler feststellt, dass der Heap untätig war und das Ziel überschreitet oder wenn debug.FreeOSMemory() aufgerufen wird.
Wird die Goroutine während des Stapelverkleinerns gestoppt, und wie werden Zeiger aktualisiert?
Ja, das Verkleinern erfordert das Stoppen der Zielgoroutine an einem sicheren Punkt, ähnlich wie beim Wachstum des Stapels. Die Laufzeit muss lebendige Frames an einen neuen Speicherort kopieren und alle Zeiger aktualisieren, die auf stapelzugeordnete Variablen verweisen. Der Compiler erzeugt Zeigerkarten, die identifizieren, welche Wörter in jedem Frame Zeiger sind. Während des Verkleinerns verwendet die Laufzeit diese Karten, um innere Zeiger zu finden und anzupassen, damit sie auf die neuen Stapeladressen verweisen. Dieser Vorgang ist nicht gleichzeitig; die Goroutine kann während des Kopierens nicht ausgeführt werden, aber andere Goroutinen laufen weiterhin.