This is a creation in Article, where the information may have evolved or changed. Original: Http://dave.cheney.net/2015/11/29/a-whirlwind-tour-of-gos-runtime-environment-variables
Quick tour of Go language runtime environment variables
Introduced:
In addition to services such as GC, Goroutine scheduling, timers, and network polling, Go runtime also provides a number of other tool facilities for opening additional debug outputs,
or change some of the behavior of Go runtime itself. These tool facilities are controlled by some of the environment variables passed to go program, which are mainly described in this article.
GOGC
GOGC is the first environment variable supported by Go runtime, even earlier than Goroot, and almost no one knows. The GOGC is used to control the frequency at which the GC is sent, and its value defaults to 100.
The GC does not trigger a run until the heap size has increased by 100% since the last garbage collection. That is, gogc=100 means that the live heap size increases by one times, and the GC triggers the run once.
If the gogc=200 is set, the live heap size increases twice times since the last garbage collection, the GC triggers the run, in short, the higher the value of the GC trigger the lower the frequency, the higher the inverse,
If Gogc=off closes the GC.
Although go 1.5 introduces a low-latency GC, the effect of GOGC on the frequency of GC runs remains the same as its value greater than 100, the higher the GC runs,
Conversely, the lower.
Gotraceback
Gotraceback is used to control how detailed the system provides information when an exception occurs, and in Go 1.5, Gotraceback has 4 values.
Gotraceback=0 only outputs panic exception information.
Gotraceback=1 This is the default setting value for Go, output all goroutine stack traces, removing the stack frames associated with Go runtime.
Based on Gotraceback=1, gotraceback=2 also outputs the stack frames associated with go runtime to see which Goroutines are run by Go runtime.
Gotraceback=crash, on the basis of gotraceback=2, go runtime segfault errors to generate core dump, of course, the operating system allows, rather than invoking the OS. Exit.
The following is an example of a code test for Gotraceback
Package Main
Func Main () {
Panic ("Kerboom")
}
Operation Result:
$ env gotraceback=0./crash
Panic:kerboom
$ echo $?
2
Readers are interested in trying other values to see the effect.
gotraceback changes in Go 1.6
Gotraceback=none only outputs panic exception information.
Gotraceback=single only outputs information about the goroutine that is considered to be causing the panic exception.
Gotraceback=all outputs all goroutines related information, removing the stack frames associated with Go runtime.
Gotraceback=system outputs all goroutines information, including the stack frames associated with the Go runtime, to learn which Goroutine go runtime startup.
The Gotraceback=crash is the same as Go 1.5, unchanged.
To be compatible with go 1.5, 0 corresponds to None, 1 corresponds to all, and 2 corresponds to the system.
Note: In Go 1.6, by default, only the stack trace of the goroutine that raised the Panci exception is output.
Gomaxprocs
Gomaxprocs are familiar with the number of threads used to control the operating system, which are used to run goroutines in Go programs.
To go 1.5, the default value of Gomaxprocs is the number of CPUs that the operating system is aware of when our go program starts.
Note: The number of operating system threads used in our Go program also includes: the thread that is serving CGO calls, blocking the thread of the operating system calls,
So the number of operating system threads used in the Go program may be greater than the Gomaxprocs value.
Godebug
The mouse pulls the spade, the big head is behind, the remainder of this article mainly talk about Godebug. The value of the godebug is interpreted as a
Name=value Yes, each pair is separated by commas, and each pair is used to control the Go Runtime Debugging Tools facility, for example:
$ env godebug=gctrace=1,schedtrace=1000 godoc-http=:8080
The above command is used to turn on GC tracing and schedule tracing when running the Godoc program.
Here are some of the more useful debugging tools facilities
Gctrace
This tool I think is the most useful, please see the program output will know
$ env godebug=gctrace=1 Godoc-http=:8080-index
GC #1 @0.042s 4%: 0.051+1.1+0.026+16+0.43 ms Clock, 0.10+1.1+0+2.0/6.7/0+0.86 MS CPU, 4->32->10 MB, 4 MB goal, 4 P
GC #2 @0.062s 5%: 0.044+1.0+0.017+2.3+0.23 ms Clock, 0.044+1.0+0+0.46/2.0/0+0.23 MS CPU, 4->12->3 MB, 8 MB goal, 4 P
GC #3 @0.067s 6%: 0.041+1.1+0.078+4.0+0.31 ms Clock, 0.082+1.1+0+0/2.8/0+0.62 MS CPU, 4->6->4 MB, 8 MB goal, 4 P
GC #4 @0.073s 7%: 0.044+1.3+0.018+3.1+0.27 ms Clock, 0.089+1.3+0+0/2.9/0+0.54 MS CPU, 4->7->4 MB, 6 MB goal, 4 P
The output format of this information changes with each of the different versions of Go, but it is always possible to find common things, such as: The amount of time spent per GC phase, the amount of change in the heap size,
Also includes each GC phase completion time, relative to the time the program started, of course, the old version of Go may omit some information.
Each line of information is useful, but I think it is more useful to analyze this information in a comprehensive sense, for example, the continuous output of GC tracing can clearly indicate the memory allocation of the program,
The growing heap size indicates that there may be memory leaks, and perhaps some of the referenced items have not been released.
The cost of opening the gctrace is very small, but it is usually closed, but I recommend in some product environments to extract some
Sample product, open this debugging tool.
The original text was not translated and the exact expression was not found.
Note:setting Gctrace to values larger than 1 causes all garbage collection cycle to be run twice.
This exercises some aspects of finalisation that require the garbage collection cycles to complete.
You should don't use this as a mechanism to alter finalisation performance in your programs because you should not write pro Grams who's correctness depends on finalisation.
The heap Scavenger
So far, the most useful information given by Gctrace is the output of the heap scavenger.
Scvg143:inuse:8, idle:104, sys:113, released:104, Consumed:8 (MB)
Scavenger's job is to periodically clean the heap of useless operating system memory paging, it will be issued to the operating system build justice, the operating system to reclaim useless memory pages,
Of course, the operating system cannot be forced to do the recycling process immediately, the operating system can ignore this justification, or delay the recovery, such as until the allocated free memory is not enough.
The scavenger output is the best way for us to understand the use of the Go program's virtual memory space, but you can also get this information through other tools like free, top,
But you apply trust scavenger.
Schedtrace
Because go runtime manages a large number of goroutine and dispatches Goroutine to run on the operating system thread set,
This set of operating system threads is actually a thread pool, so we can't get enough details from the outside to examine the performance of Go programs.
Not to mention accurate analysis of program performance. So we need to get a straight look at every operation of the Go Runtime Scheduler, with the following output:
$ env godebug=schedtrace=1000 Godoc-http=:8080-index
SCHED 0ms:gomaxprocs=4 idleprocs=2 threads=4 spinningthreads=1 idlethreads=0 runqueue=0 [0 0 0 0]
SCHED 1001ms:gomaxprocs=4 idleprocs=0 threads=8 spinningthreads=0 idlethreads=2 runqueue=0 [189 197 231 142]
SCHED 2004ms:gomaxprocs=4 idleprocs=0 threads=9 spinningthreads=0 Idlethreads=1 runqueue=0 [54 45 38 86]
SCHED 3011ms:gomaxprocs=4 idleprocs=0 threads=9 spinningthreads=0 idlethreads=2 runqueue=2 [85 0 67 111]
SCHED 4018ms:gomaxprocs=4 idleprocs=3 threads=9 spinningthreads=0 idlethreads=4 runqueue=0 [0 0 0 0]
For a detailed discussion please see Dmitry Vyukov's excellent blog post from the Intel Developerzone.
Setting scheddetail=1 will let go runtime output summary information, and output each goroutine status information, such as:
$ env godebug=scheddetail=1,schedtrace=1000 Godoc-http=:8080-index
SCHED 0ms:gomaxprocs=4 idleprocs=3 threads=3 spinningthreads=0 idlethreads=0 runqueue=0 gcwaiting=0 nmidlelocked=0 Stopwait=0 sysmonwait=0
P0:status=1 schedtick=0 syscalltick=0 m=0 runqsize=0 gfreecnt=0
P1:status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0
P2:status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0
P3:status=0 schedtick=0 syscalltick=0 m=-1 runqsize=0 gfreecnt=0
M2:p=-1 curg=-1 mallocing=0 throwing=0 preemptoff= locks=1 dying=0 helpgc=0 spinning=false blocked=false lockedg=-1
M1:p=-1 curg=17 mallocing=0 throwing=0 preemptoff= locks=0 dying=0 helpgc=0 spinning=false blocked=false lockedg=17
M0:p=0 curg=1 mallocing=0 throwing=0 preemptoff= locks=2 dying=0 helpgc=0 spinning=false blocked=false lockedg=1
g1:status=2 (stack growth) m=0 lockedm=0
G17:status=3 () M=1 lockedm=1
G2:status=1 () M=-1 lockedm=-1
This output is useful for debugging goroutines leaking, but other tools, such as: Net/http/pprof
It seems to be more useful.
To read more, see the Godoc for the runtime package.
Note: This article is only my personal notes, if there are errors and omissions, please correct me, study together, my e-mail: htyu_0203_39@sina.com
