GC Information for Golang

This is a creation in Article, where the information may have evolved or changed.

This article transferred from: http://studygolang.com/articles/2701

I. Information collection of GC information

Set the environment variable godebug=gctrace=1.

Use the method if the program is myserver. The normal startup method is./myserver, if you need to collect GC information starting with the following godebug=gctrace=1./myserver.

Second, GC information analysis

GC5 (6): 11+12+357+77 us, 0, 1 MB, 4294 (5261-967) objects, 67/2/0 sweeps, 6 (handoff), 6 (9) steal, 170/56/5 yields

GC5 (6): Represents the 5th GC, with a total of 6 threads participating in the GC.

11+12+357+77 US: Indicates that stopping each goroutine takes time to be 11us, releasing the tagged object all the time is 12us, and scanning the tagged recyclable object takes time to 257us, completing the end of each thread as 17us. GC Total time is 457us.

0-1 MB: Indicates that the heap occupies a space of 0MB after the last GC, and the pre-GC heap occupies 1MB.

4294 (5261-967) objects: Indicates that the number of remaining non-freed objects is 4,294, the GC has 5,261 objects before it, and the GC frees 967 objects.

The basic rule is that the more current objects, the longer the scan time, the more objects you need to release, and the longer the release process.

Iii. what the GC needs to be aware of

Because the GC process in the Golang need to stop all goroutine in the program, resulting in a program like tamping, so for the real-time requirements of a relatively high program to use the Golang language carefully. A recommended recommendation is to reduce the number of objects if you want to reduce GC time, so if you can reuse objects in your code as much as possible. To reduce the number of temporary objects, thereby reducing GC time.

Of course the GC can be turned off, so that a program with high real-time requirements can recommend an implementation pattern:

With a master process Fock out two sub-processes, two sub-processes provide services in turn, one child process to provide service, and another child process to hibernate. When the child process that provides the service has been working for a period of time after the number of objects has accumulated too much, waking up another child process to start working, the notebook process begins to GC,GC and goes into hibernation waiting to be awakened. This avoids the problem of irregular compaction caused by GC problems.

Iv. recommendations

For the high-real-time requirements of the program, be sure to focus on GC issues. Because Golang's GC is very immature, it's far from Java, and if you don't care about GC issues, it's likely to cause project failure. Maybe in the future, Golang's GC is as good as Java, and that's useless.

V. References:

https://software.intel.com/en-us/blogs/2014/05/10/debugging-performance-issues-in-go-programs