[[435409]]

關于 Go GC 優化的手段你知道的有哪些?比較常見的是通過調整 GC 的步調，以調整 GC 的觸發頻率。

• 設置 GOGC
• 設置 debug.SetGCPercent()

這兩種方式的原理和效果都是一樣的，GOGC 默認值是 100，也就是下次 GC 觸發的 heap 的大小是這次 GC 之后的 heap 的一倍。

我們都知道 GO 的 GC 是標記-清除方式，當 GC 會觸發時全量遍歷變量進行標記，當標記結束后執行清除，把標記為白色的對象執行垃圾回收。值得注意的是，這里的回收僅僅是標記內存可以返回給操作系統，并不是立即回收，這就是你看到 Go 應用 RSS 一直居高不下的原因。在整個垃圾回收過程中會暫停整個 Go 程序(STW)，Go 垃圾回收的耗時還是主要取決于標記花費的時間的長短，清除過程是非常快的。

設置 GOGC 的弊端

1. GOGC 設置比率的方式不精確

設置 GOGC 基本上我們比較常用的 Go GC 調優的方式，大部分情況下其實我們并不需要調整 GOGC 就可以，一方面是不涉及內存密集型的程序本身對內存敏感程度太低，另外就是 GOGC 這種設置比率的方式不精確，我們很難精確的控制我們想要的觸發的垃圾回收的閾值。

2. GOGC 設置過小

GOGC 設置的非常小，會頻繁觸發 GC 導致太多無效的 CPU 浪費，反應到程序的表現就會特別明顯。舉個例子，對于 API 接口來說，導致的結果的就是接口周期性的耗時變化。這個時候你抓取 CPU profile 來看，大部分的耗時都集中在 GC 的相關處理上。

如上圖，這是一次 prometheus 的查詢操作，我們看到大部分的 CPU 都消耗在 GC 的操作上。這也是生產環境遇到的，由于 GOGC 設置的過小，導致過多的消耗都耗費在 GC 上。

3. 對某些程序本身占用內存就低，容易觸發 GC

對 API 接口耗時比較敏感的業務，如果 GOGC 置默認值的時候，也可能也會遇到接口的周期性的耗時波動。這是為什么呢?

因為這種接口本身占用內存比較低，每次 GC 之后本身占的內存比較低，如果按照上次 GC 后的 heap 的一倍的 GC 步調來設置 GOGC 的話，這個閾值其實是很容易就能夠觸發，于是就很容出現接口因為 GC 的觸發導致額外的消耗。

4. GOGC 設置很大，有的時候又容易觸發 OOM

那如何調整呢?是不是把 GOGC 設置的越大越好呢?這樣確實能夠降低 GC 的觸發頻率，但是這個值需要設置特別大才有效果。這樣帶來的問題，GOGC 設置的過大，如果這些接口突然接受到一大波流量，由于長時間無法觸發 GC 可能導致 OOM。

由此，GOGC 對于某些場景并不是很友好，那有沒有能夠精確控制內存，讓其在 10G 的倍數時準確控制 GC 呢?

GO 內存 ballast

這就需要 Go ballast 出場了。什么是 Go ballast，其實很簡單就是初始化一個生命周期貫穿整個 Go 應用生命周期的超大 slice。

func main() { 
  ballast := make([]byte, 10*1024*1024*1024) // 10G  
   
  // do something 
   
  runtime.KeepAlive(ballast) 
} 

上面的代碼就初始化了一個 ballast，利用 runtime.KeepAlive 來保證 ballast 不會被 GC 給回收掉。

利用這個特性，就能保證 GC 在 10G 的一倍時才能被觸發，這樣就能夠比較精準控制 GO GC 的觸發時機。

這里你可能有一個疑問，這里初始化一個 10G 的數組，不就占用了 10 G 的物理內存呢? 答案其實是不會的。

package main 
 
import ( 
    "runtime" 
    "math" 
    "time" 
) 
 
func main() { 
    ballast := make([]byte, 10*1024*1024*1024) 
 
    <-time.After(time.Duration(math.MaxInt64)) 
    runtime.KeepAlive(ballast) 
} 

$ ps -eo pmem,comm,pid,maj_flt,min_flt,rss,vsz --sort -rss | numfmt --header --to=iec --field 5 | numfmt --header --from-unit=1024 --to=iec --field 6 | column -t | egrep "[t]est|[P]I" 
 
%MEM  COMMAND   PID    MAJFL      MINFL  RSS    VSZ 
0.1   test      12859  0          1.6K   344M   11530184 

這個結果是在 CentOS Linux release 7.9 驗證的，我們看到占用的 RSS 真實的物理內存只有 344M，但是 VSZ 虛擬內存確實有 10G 的占用。

延伸一點，當懷疑我們的接口的耗時是由于 GC 的頻繁觸發引起的，我們需要怎么確定呢?首先你會想到周期性的抓取 pprof 的來分析，這種方案其實也可以，但是太麻煩了。其實可以根據 GC 的觸發時間繪制這個曲線圖，GC 的觸發時間可以利用 runtime.Memstats 的 LastGC 來獲取。

生產環境驗證

• 綠線 調整前 GOGC = 30
• 黃線 調整后 GOGC 默認值，ballast = 100G

這張圖相同的流量壓力下，ballast 的表現明顯偏好。

結論

本篇文章只是簡單的闡述了 Go ballast 的使用，Go ballast 是官方比較認可的方案，具體可以參見 issue 23044[1]。很多開源程序，如 tidb[2]，cortex[3] 都實現了 go ballast，如果你的程序飽受 GOGC 的問題影響或者周期性的耗時不穩定，不妨嘗試下 go ballast。 

當然強烈推薦你看下twitch.tv 這篇文章[4]，相信讓你會對 GOGC 以及 ballast 的運用理解的更加透徹。