[[409549]]

本文轉(zhuǎn)載自微信公眾號(hào)「董澤潤(rùn)的技術(shù)筆記」，作者董澤潤(rùn) 。轉(zhuǎn)載本文請(qǐng)聯(lián)系董澤潤(rùn)的技術(shù)筆記公眾號(hào)。

本文是在上家的 case, 以前很多人在公開大會(huì)上拿該案例做分享，所以覺得有印象的同學(xué)勿噴，雖然冷飯，但是原創(chuàng)，而且干貨十足 ^_^

有時(shí)大家很不理解的現(xiàn)象，明明 call RPC 時(shí)設(shè)置了超時(shí)時(shí)間 timeout, 但是 Grafna 看到 P99 latency 很高，why ???

不要猶豫，要么是 timeout 設(shè)置不合理，比如只設(shè)置了單次 socket timeout, 并沒有設(shè)置 circuit breaker 外層超時(shí)。參考 你真的了解 timeout 嘛[1]

還有一種情況就是 GC 在搗亂，我們知道 Go GC 使用三色標(biāo)記法，在 GC 壓力大時(shí)用戶態(tài) goroutine 是要 assit 協(xié)助標(biāo)記對(duì)象的，同時(shí) GC STW 時(shí)間如果非常高，那么業(yè)務(wù)看起來 latency 就會(huì)得比 timeout 大很多

毛刺

該服務(wù)使用 go1.7, 需要加載海量的機(jī)器學(xué)習(xí)詞表，標(biāo)準(zhǔn)的 Go 大內(nèi)存服務(wù)，優(yōu)化前表現(xiàn)為 latency 非常高

可以看到最大的己經(jīng)到了 2s

同時(shí)查看 GC PauseNS 也非?？膳?，基本接近 1s, 服務(wù)處理不可用狀態(tài)

Pprof

如何開啟 pprof 這里就不寫了，網(wǎng)上有很多，大家可以自行查看

go tool pprof bin/dupsdc http://127.0.0.1:6060/debug/pprof/profile 

可以看到 runtime.greyobject, runtime.mallocgc, runtime.heapBitsForObject, runtime.scanobject, runtime.memmove 就些與 GC 相關(guān)的占據(jù)了 CPU 消耗的 TOP 6

go tool pprof -inuse_objects http://127.0.0.1:6060/debug/pprof/heap 

再查看下常駐對(duì)像個(gè)數(shù)，發(fā)現(xiàn) 1kw 常駐內(nèi)存對(duì)像(現(xiàn)在來看很小了，不多)，這些都是詞表加載的小對(duì)像

優(yōu)化對(duì)像

詞表主要使用兩種類型，map[int64][]float32 和 map[string]int

讓我們看一下三色標(biāo)記，本質(zhì)是遞歸掃描所有的指針類型，遍歷確定有沒有被引用

那么問題來了，什么是指針類型呢???所有顯示 *T 以及內(nèi)部有 pointer 的對(duì)像都是指針類型，比如 map[int64][]float32 因?yàn)橹凳? slice, 內(nèi)部包含了指針，如果 map 有 1kw 個(gè)元素，那么 GC 也要遞歸所描所有 key/value

了解這些，優(yōu)化方法就來了，把 map[int64][]float32 變成 map[int64][6]float32, 這里 slice 變成 6 個(gè)元素的數(shù)組，業(yè)務(wù)可以接受

同時(shí)把 map[string]int 里的 key 由 string 類型換成 int 枚舉值

優(yōu)化效果

上線后優(yōu)化效果很明顯

可以看到，常駐內(nèi)存對(duì)像由 1kw 降低到 200w

同時(shí) cpu pprof 也能看到，排名第一的是 syscall, GC 相關(guān)的己經(jīng)降低很多

查看 Grafana 外圍 IO latency 降低非常明顯。整體優(yōu)化效果不錯(cuò)

例外

這里也有例外，比如 map 內(nèi)部的實(shí)現(xiàn)，如果 key/value 值類型大小超過 128 字節(jié)，就會(huì)退化成指針

// Builds a type representing a Bucket structure for 
// the given map type. This type is not visible to users - 
// we include only enough information to generate a correct GC 
// program for it. 
// Make sure this stays in sync with runtime/map.go. 
const ( 
 BUCKETSIZE  = 8 
 MAXKEYSIZE  = 128 
 MAXELEMSIZE = 128 
) 

// bmap makes the map bucket type given the type of the map. 
func bmap(t *types.Type) *types.Type { 
 if t.MapType().Bucket != nil { 
  return t.MapType().Bucket 
 } 
 
 bucket := types.New(TSTRUCT) 
 keytype := t.Key() 
 elemtype := t.Elem() 
 dowidth(keytype) 
 dowidth(elemtype) 
 if keytype.Width > MAXKEYSIZE { 
  keytype = types.NewPtr(keytype) 
 } 
 if elemtype.Width > MAXELEMSIZE { 
  elemtype = types.NewPtr(elemtype) 
 } 
 
 field := make([]*types.Field, 0, 5) 
  ...... 
} 

思考

Go 每個(gè)版本性能都會(huì)提升很多，go1.7 1kw 對(duì)像服務(wù)壓力非常大，但是我司現(xiàn)在 go1.15 2kw 對(duì)像未優(yōu)化也毫無壓力

Go 在吞吐量方面優(yōu)化非常顯著。還是那句話，本文只做為 GC 性能分析參考，不要提前優(yōu)化

另外一方面也說明，Go 三色標(biāo)記并不適合所有場(chǎng)景，本次分享的大詞表常駐內(nèi)存就是一個(gè)典型：

很明顯的 old objects, 不需要 GC 每次都掃描，這里羨慕 java 的分代 GC