Ist der Garbage Collector von Go 1.5 für die Speicherverwaltung im Terabyte-Bereich bereit?

Wie schnell ist Go 1,5 GC mit Terabyte RAM?

Hintergrund:

Java steht vor der GC-Unterbrechungszeit A Ein zu langer Engpass kann Terabytes an Speicher nicht effektiv nutzen. Da Go GC optimiert ist, fragen sich die Leute, ob es in einer Speicherumgebung auf Terabyte-Ebene eine ausreichend kurze GC-Unterbrechungszeit erreichen kann.

Frage:

• Ist der Go 1.5 GC bereit, Terabytes an Speicher zu verarbeiten?
• Gibt es relevante Benchmarks?
• Ist es möglich, eine Sprache mit GC zu verwenden, um einen so großen Speicher zu verwalten?

Antwort:

Punkte:

• Derzeit kann ein einzelner Go-Prozess keine Terabytes verwenden Erinnerung . Die Höchstgrenze unter Linux liegt bei 512 GB, während die in realen Tests ermittelte Höchstgrenze nur 240 GB betrug.
• Im aktuellen Hintergrund-GC-Modus ist die GC-Arbeitslast oft kritischer als die GC-Interruptzeit.
• GC-Arbeitslast kann durch die Anzahl der Zeiger * Zuordnungsrate / verbleibender Speicher dargestellt werden. In Anwendungen, die viel Speicher verbrauchen, können nur Anwendungen mit einer geringeren Anzahl von Zeigern oder weniger Zuweisungen die GC-Arbeitslast niedrig halten.

Details:

Der Go-Heap hat ein Limit von 512 GB und die tatsächlich getestete maximale Heap-Größe beträgt 240 GB.

Go 1.5 GC wurde entwickelt, um die GC-Unterbrechungszeit zu verkürzen, nicht um die GC-Arbeit zu reduzieren. Der Code wird unterbrochen, während der GC den Stapel und Zeiger in globalen Variablen scannt.

Laut dem Diagramm aus dem GopherCon-Vortrag 2015 hat der 1,5 GC im GC-Benchmark mit ~18 GB Heap geringere Ausfallzeiten, wie gezeigt:

[Diagramm: GC-Ausfallzeiten Beziehung zum Heap Größe, zeigt Verbesserungen in Version 1.5]

In tatsächlichen Anwendungen gelten einige ursprüngliche GC-Unterbrechungszeiten Ein Prozessbericht von 300 ms sank auf 4 ms und 20 ms, und eine andere Anwendung meldete eine 95. Perzentil-GC-Zeit von 279 ms auf 10 ms.

Go 1.6 ist weiter optimiert und verlagert einige Arbeit in den Hintergrund. Das Ergebnis ist, dass selbst wenn die Heap-Größe 200 GB überschreitet, die maximale Interrupt-Zeit im Test immer noch 20 ms beträgt, wie in der folgenden Abbildung dargestellt:

[Diagramm: 1,6 GC-Zeit ändert sich mit der Heap-Größe und erreicht etwa 20 ms 180 GB]

In Version 1.6 beträgt die Heap-Größe etwa 8 GB und die Anwendung weist etwa 150 MB pro Minute zu. Die Unterbrechungszeit beträgt 20 ms auf 3-4 ms reduziert.

Twitch nutzt Go zum Ausführen seines Chat-Dienstes und berichtet, dass in Version 1.7 die Pausenzeiten auf 1 ms reduziert wurden, während eine große Anzahl von Coroutinen gleichzeitig ausgeführt wird.

1.8 Verschieben Sie das Stack-Scanning aus der Stop-the-World-Phase, sodass die meisten Interrupt-Zeiten unter 1 ms bleiben, selbst bei großen Heaps. Erste Testergebnisse deuten auf gute Bedingungen hin. Manchmal gibt es in der Anwendung immer noch Codemuster, die das Unterbrechen von Coroutinen erschweren und die Interruptzeit für alle anderen Threads effektiv verlängern, aber insgesamt ist die Hintergrundarbeit des GC normalerweise wichtiger als die GC-Interruptzeit.

Allgemeine Beobachtungen:

• Die Erfassungshäufigkeit von GC hängt von der Geschwindigkeit der Speichernutzung ab.
• Der Arbeitsaufwand jeder GC-Sammlung hängt teilweise von der Anzahl der verwendeten Zeiger ab. (Einschließlich Zeiger in Slices, Schnittstellenwerten, Zeichenfolgen usw.)

Mit anderen Worten, auch wenn die Anwendung auf viel Speicher zugreift, wenn die Anzahl der Zeiger gering ist (z. B. verarbeitet sie relativ wenig [] Byte-Puffer) und die Zuordnungsrate niedrig ist (z. B. weil sync.Pool zur Wiederverwendung von Speicher in den anfälligsten für Speicherüberlaufszenarien angewendet wird), besteht das GC-Problem möglicherweise nicht.

Wenn Sie also einen großen Computer mit Hunderten von GB Heap in Betracht ziehen und dieser von Natur aus für GC ungeeignet ist, empfehle ich Ihnen, die folgenden Optionen in Betracht zu ziehen:

1. Verwenden Sie C oder ähnliches language Writing
2. verschiebt große Datenmengen aus dem Objektgraphen, z. B. um sie als eingebettete Datenbank zu verwalten (z. B. Bolt) in einen externen Datenbankdienst integrieren oder wenn Sie mehr Caching-Funktionen als eine Datenbank benötigen, können Sie ein Caching-Tool wie Groupcache oder Memcache verwenden.
3. Führen Sie eine Reihe von Prozessen aus, die einen kleineren Heap anstelle eines großen Prozesses verwenden.
4. Sorgfältig prototypisiert, getestet und optimiert, um Speicherprobleme zu vermeiden.

Das obige ist der detaillierte Inhalt vonIst der Garbage Collector von Go 1.5 für die Speicherverwaltung im Terabyte-Bereich bereit?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!