Go 1.3 Garbage Collector gibt Serverspeicher nicht wieder an das System frei
Ein Server, der zur Untersuchung des Speicherbedarfs entwickelt wurde, zeigt schwankenden RES-Speicher trotz erwarteter Speicherfreigabe nach einem Anstieg der Verbindungen. Das Problem entsteht aufgrund der Einschränkungen des Go-Garbage Collectors bei der sofortigen Freigabe von Heap-Speicher und der Unzugänglichkeit des Goroutine-Stack-Speichers für das Betriebssystem. Ein in Unix-ähnlichen Systemen verfügbarer Systemaufruf zum Freigeben ungenutzter Heap-Teile ist unter Windows nicht verfügbar, was möglicherweise zu einem größeren virtuellen Speicherverbrauch führt.
Zunächst startet der Server mit einer geringfügigen Speicherbelegung. Während des ersten Impulses von 10.000 Verbindungen steigt die Speichernutzung auf etwa 60 MB (wie durch die RES-Größe in „oben“ angezeigt). Wenn der Impuls endet, nimmt die Speichernutzung ab. Die RES-Größe bleibt jedoch bei 56 MB erhöht, während der verwendete Speicher nie unter 60 MB fällt.
Der Go-Garbage Collector gibt zwar Heap-Speicher frei, gibt ihn jedoch nicht sofort an das System zurück. Dieser Vorgang kann nach dem GC-Sweep bis zu sieben Minuten dauern. Darüber hinaus wird der den Goroutine-Stacks zugewiesene Speicher niemals an das Betriebssystem freigegeben. Dies trägt zum anhaltend hohen Speicherverbrauch des Servers bei.
Leider gibt es in Go Version 1.3 keine klare Lösung für dieses Problem. Es wird jedoch erwartet, dass sich die Situation in späteren Versionen verbessert. Um die Auswirkungen zu mildern, ziehen Sie die folgenden Maßnahmen in Betracht:
Das obige ist der detaillierte Inhalt vonWarum gibt Go 1.3 den Serverspeicher nach einer Verbindungsspitze nicht wieder an das System zurück?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!