原文： http://dave.cheney.net/2015/11/29/a-whirlwind-tour-of-gos-runtime-environment-variables

Go 語言運行時環境變量快速導覽

介紹：

Go Runtime除了提供:GC, goroutine調度， 定時器，network polling等服務外， 還提供其它一些工具設施，用于開啟額外的調試輸出，

或是改變Go Runtime自身的一些行為。這些工具設施由傳給Go program的一些環境變量控制， 本文主要講述它們。

GOGC

GOGC 是Go Runtime最早支持的環境變量，甚至比GOROOT還早，幾乎無人不知。GOGC 用于控制GC的處發頻率， 其值默認為100,

意為直到自上次垃圾回收后heap size已經增長了100%時GC才觸發運行。即是GOGC=100意味著live heap size 每增長一倍，GC觸發運行一次。

如設定GOGC=200, 則live heap size 自上次垃圾回收后，增長2倍時，GC觸發運行， 總之，其值越大則GC觸發運行頻率越低， 反之則越高，

如果GOGC=off 則關閉GC.

雖然go 1.5引入了低延遲的GC, 但是GOGC對GC運行頻率的影響不變， 仍然是其值大于100,則越大GC運行頻率越高，

反之則越低。

GOTRACEBACK

GOTRACEBACK用于控制當異常發生時，系統提供信息的詳細程度， 在go 1.5， GOTRACEBACK有4個值。

GOTRACEBACK=0 只輸出panic異常信息。

GOTRACEBACK=1 此為go的默認設置值， 輸出所有goroutine的stack traces, 除去與go runtime相關的stack frames.

GOTRACEBACK=2 在GOTRACEBACK=1的基礎上， 還輸出與go runtime相關的stack frames,從而了解哪些goroutines是由go runtime啟動運行的。

GOTRACEBACK=crash, 在GOTRACEBACK=2的基礎上，go runtime處發進程segfault錯誤，從而生成core dump, 當然要操作系統允許的情況下， 而不是調用os.Exit。

以下為GOTRACEBACK的代碼測試例子

package main

func main() {

panic("kerboom")

}

運行結果：

$ env GOTRACEBACK=0 ./crash

panic: kerboom

$ echo $?

2

讀者有興趣可以嘗試其它值， 看看效果。

GOTRACEBACK 在go 1.6中的變化

GOTRACEBACK=none 只輸出panic異常信息。

GOTRACEBACK=single 只輸出被認為引發panic異常的那個goroutine的相關信息。

GOTRACEBACK=all 輸出所有goroutines的相關信息，除去與go runtime相關的stack frames.

GOTRACEBACK=system 輸出所有goroutines的相關信息，包括與go runtime相關的stack frames,從而得知哪些goroutine是go runtime啟動運行的。

GOTRACEBACK=crash 與go 1.5相同， 未變化。

為了與go 1.5兼容，0 對應 none, 1 對應 all, 以及 2 對應 system.

注意： 在go 1.6中， 默認，只輸出引發panci異常的goroutine的stack trace.

GOMAXPROCS

GOMAXPROCS 大家比較熟悉， 用于控制操作系統的線程數量， 這些線程用于運行go程序中的goroutines.

到go 1.5的時候， GOMAXPROCS的默認值就是我們的go程序啟動時可見的操作系統認為的CPU個數。

注意： 在我們的go程序中使用的操作系統線程數量，也包括：正服務于cgo calls的線程, 阻塞于操作系統calls的線程，

所以go 程序中使用的操作系統線程數量可能大于GOMAXPROCS的值。

GODEBUG

老鼠拉鐵鍬，大頭在后邊， 本文其余篇幅主要講講GODEBUG. GODEBUG的值被解釋為一個個的

name=value對， 每一對間由逗號分割，每一對用于控制go runtime 調試工具設施， 例如：

$ env GODEBUG=gctrace=1,schedtrace=1000 godoc -http=:8080

上面這條命令用于運行godoc程序時開啟 GC tracing and schedule tracing.

下面開始介紹幾個比較有用的調試工具設施

gctrace

這個工具我認為最有用處了，請看程序輸出便知

$ 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

此信息的輸出格式隨著go的每一不同的版本發生變化，但總是能發現共性的東西， 如： 每一GC 階段所花費的時間量， heap size 的變化量，

也包括每一GC階段完成時間，相對于程序啟動時的時間，當然老版本go可能省略一些信息。

每一行信息都很有用， 不過我認為綜合分析這些信息則更有用，比如， 不斷輸出的gc tracing,可以清楚在表明程序的內存分配情況，

持續不斷增長的heap size 則表明可能有內存泄露，也許一些被引用的東西沒有被釋放。

開啟gctrace的代價是很小的，不過其通常是關閉的， 不過我推薦在一些產品環境中，抽取一些

樣本產品，開啟這個調試工具。

原文未翻譯，未找到準確表述。

note:setting gctrace to values larger than 1 causes each garbage collection cycle to be run twice.

This exercises some aspects of finalisation that require two garbage collection cycles to complete.

You should not use this as a mechanism to alter finalisation performance in your programs because you should not write programs who’s correctness depends on finalisation.

The heap scavenger

到目前為止，gctrace給出的最有用的信息就是 the heap scavenger的輸出.

scvg143: inuse: 8, idle: 104, sys: 113, released: 104, consumed: 8 (MB)

scavenger 的工作就是周期性地打掃heap中無用的操作系統內存分頁， 它會向操作系統發出建義，請操作系統回收無用內存頁，

當然并不能強迫操作系統立刻就去做回收處理，操作系統可以忽略此建義，或是延遲回收，比如直到可分配的空閑內存不夠的時候。

scavenger輸出的信息是我們了解go程序虛擬內存空間使用情況的最好方式， 當然你也可以通過其它工具，如free, top來獲到這些信息，

不過你應用信任scavenger.

schedtrace

因為go runtime管理著大量的goroutine, 并調度goroutine在操作系統線程集上運行，

這個操作系統線程集，其實是就是線程池， 所以從外部考察go程序的性能我們不能獲取足夠的細節信息，

更談不上準確分析程序性能。故此我們需要直接了解go runtime scheduler的每一個操作，其輸出如下：

$ 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]

詳細討論請看 Dmitry Vyukov’s excellent blog post from the Intel DeveloperZone.

設定scheddetail=1將使go runtime輸出總結性信息時， 一并輸出每一個goroutine的狀態信息，如：

$ 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

這個輸出對于調試goroutines leaking很有幫助， 不過其它工具， 諸如：net/http/pprof

好像更有用一些。

深入閱讀請看godoc for the runtime package.