Is Go 1.5\'s Garbage Collector Ready for Terabyte-Scale Memory Management?

How Fast Is the Go 1.5 GC with Terabytes of RAM?

Background:

Java faces GC interruption time A bottleneck that is too long cannot effectively utilize terabytes of memory. As Go GC is optimized, people can't help but wonder whether it can achieve short enough GC interruption time in a terabyte-level memory environment.

Question:

• Is the Go 1.5 GC ready to handle terabytes of memory?
• Are there any relevant benchmarks?
• Is it possible to use a language with GC to manage such a huge memory?

Answer:

Points:

• Currently, a single Go process cannot use terabytes of memory . The maximum limit on Linux is 512 GB, while the highest recorded in real-world testing was only 240 GB.
• In the current background GC mode, GC workload is often more critical than GC interrupt time.
• GC workload can be represented by the number of pointers * allocation rate / remaining memory. In applications that use a lot of memory, only applications with a smaller number of pointers or fewer allocations can keep the GC workload low.

Details:

The Go heap has a limit of 512 GB, and the actual tested maximum heap size is 240 GB.

Go 1.5 GC is designed to reduce GC interruption time, not reduce GC work. The code is interrupted while the GC scans the stack and pointers in global variables.

According to the chart from the GopherCon 2015 talk, the 1.5 GC has lower outage times in the GC benchmark with ~18GB heap, as shown:

[Chart: GC outage times Relationship with heap size, showing improvements in version 1.5]

In actual applications, some original GC interruption times are A process report of 300ms dropped to 4ms and 20ms, and another application reported a 95th percentile GC time from 279ms to 10ms.

Go 1.6 is further optimized and places some work in the background. The result is that even if the heap size exceeds 200GB, the maximum interrupt time in the test is still 20ms, as shown in the following figure:

[Chart: 1.6 GC time changes with heap size, reaching 20ms around 180GB]

In version 1.6, the heap size is about 8GB and the application allocates about 150M per minute. The interruption time is from 20ms reduced to 3-4ms.

Twitch uses Go to run their chat service, and they report that in version 1.7, pause times have been reduced to 1ms while running a large number of coroutines simultaneously.

1.8 Move stack scanning out of the stop-the-world phase, keeping most interrupt times under 1ms, even with large heaps. Early test results indicate good conditions. Sometimes there are still code patterns in the application that make coroutines difficult to interrupt, effectively extending the interrupt time for all other threads, but overall the background work of the GC is usually more important than the GC interrupt time.

General observations:

• The collection frequency of GC depends on the memory usage speed.
• The amount of work done by each GC collection depends in part on the number of pointers in use. (Including pointers in slices, interface values, strings, etc.)

In other words, even if the application will access a lot of memory, if the number of pointers is small (e.g., it handles relatively few [] byte buffer), and the allocation rate is low (for example, because sync.Pool is applied to reuse memory in the most prone to memory overflow scenarios), the GC problem may not exist.

So if you are considering a large computer with hundreds of GB of heap, and it is inherently unsuitable for GC, I suggest you consider the following options:

1. Use C or similar language Writing
2. moves large amounts of data out of the object graph, e.g. to manage it as an embedded database (e.g. Bolt), into an external database service, or if you need more caching capabilities than a database, you can use a caching tool like groupcache or memcache.
3. Run a set of processes that use a smaller heap instead of one large process.
4. Carefully prototyped, tested and optimized to avoid memory issues.

The above is the detailed content of Is Go 1.5\'s Garbage Collector Ready for Terabyte-Scale Memory Management?. For more information, please follow other related articles on the PHP Chinese website!