內(nèi)存出現(xiàn)故障怎么檢修(內(nèi)存出現(xiàn)故障怎么檢修視頻)

內(nèi)存出現(xiàn)故障怎么檢修(內(nèi)存出現(xiàn)故障怎么檢修視頻)

前沿拓展：

---

問題出現(xiàn)出現(xiàn)報(bào)警！！！

在日常搬磚的某一天發(fā)現(xiàn)了某微服務(wù) bytedance.xiaoming 服務(wù)有一些實(shí)例內(nèi)存過高，達(dá)到 80%。而這個(gè)服務(wù)很久沒有上線過新版本，所以可以排除新代碼上線引入的問題。

發(fā)現(xiàn)問題后，首先進(jìn)行了遷移實(shí)例，除一臺(tái)實(shí)例留作問題排查外，其余實(shí)例進(jìn)行了遷移，遷移過后新實(shí)例內(nèi)存較低。但發(fā)現(xiàn)隨著時(shí)間推移，遷移過的實(shí)例內(nèi)存也有緩慢增高的現(xiàn)象，有內(nèi)存泄漏的表現(xiàn)。

問題定位推測(cè)一：懷疑是 goroutine 逃逸排查過程

通常內(nèi)存泄露的主因就是 goroutine 過多，因此首先懷疑 goroutine 是否有問題，去看了 goroutine 發(fā)現(xiàn)很正常，總量較低且沒有持續(xù)增長現(xiàn)象。（當(dāng)時(shí)忘記截圖了，后來補(bǔ)了一張圖，但是 goroutine 數(shù)量一直是沒有變化的）

排查結(jié)果

沒有 goroutine 逃逸問題。

推測(cè)二：懷疑代碼出現(xiàn)了內(nèi)存泄露排查過程

通過 pprof 進(jìn)行實(shí)時(shí)內(nèi)存采集，對(duì)比問題實(shí)例和正常實(shí)例的內(nèi)存使用狀況：

問題實(shí)例：

正常實(shí)例：

進(jìn)一步看問題實(shí)例的 graph：

從中可以發(fā)現(xiàn)，metircs.flushClients()占用的內(nèi)存是最多的，去定位源碼：

func (c tagCache) Set(key []byte, tt cachedTags) { if atomic.AddUint64(&c.setn, 1)&0x3fff == 0 { // every 0x3fff times call, we clear the map for memory leak issue // there is no reason to have so many tags // FIXME: sync.Map don&39;t have Len method and `setn` may not equal to the len in concurrency env samples := make([]interface{}, 0, 3) c.m.Range(func(key interface{}, value interface{}) bool { c.m.Delete(key) if len(samples) < cap(samples) { samples = append(samples, key) } return true }) // clear map logfunc(&34;[ERROR] gopkg/metrics: too many tags. samples: %v&34;, samples) } c.m.Store(string(key), tt)}

發(fā)現(xiàn)里面為了規(guī)避內(nèi)存泄露，已經(jīng)通過計(jì)數(shù)的方式，定數(shù)清理掉 sync.Map 存儲(chǔ)的 key 了。理論上不應(yīng)該出現(xiàn)問題。

排查結(jié)果

沒有代碼 bug 導(dǎo)致內(nèi)存泄露的問題。

推測(cè)三：懷疑是 RSS 的問題排查過程

這時(shí)注意到了一個(gè)事情，在 pprof 里看到 metrics 總共只是占用了 72MB，而總的 heap 內(nèi)存只有 170+MB 而我們的實(shí)例是 2GB 內(nèi)存配置，占用 80%內(nèi)存就意味著 1.6GB 左右的 RSS 占用，這兩個(gè)嚴(yán)重不符（這個(gè)問題的臨時(shí)解決方法在后文有介紹），這并不應(yīng)該導(dǎo)致內(nèi)存占用 80%報(bào)警。因此猜測(cè)是內(nèi)存沒有及時(shí)回收導(dǎo)致的。

經(jīng)過排查，發(fā)現(xiàn)了這個(gè)神奇的東西：

一直以來 go 的 runtime 在釋放內(nèi)存返回到內(nèi)核時(shí)，在 Linux 上使用的是 MADV_DONTNEED，雖然效率比較低，但是會(huì)讓 RSS（resident set size 常駐內(nèi)存集）數(shù)量下降得很快。不過在 go 1.12 里專門針對(duì)這個(gè)做了優(yōu)化，runtime 在釋放內(nèi)存時(shí)，使用了更加高效的 MADV_FREE 而不是之前的 MADV_DONTNEED。詳細(xì)的介紹可以參考這里：

https://goreview.googlesource.com/c/go/+/135395/

go1.12 的更新原文：

Go 1.12~1.15 runtime 優(yōu)化了 GC 策略，在 Linux 內(nèi)核版本支持時(shí) （> 4.5），會(huì)默認(rèn)采用更『激進(jìn)』的策略使得內(nèi)存重用更高效、延遲更低等諸多優(yōu)化。帶來的負(fù)面影響就是 RSS 并不會(huì)立刻下降，而是推遲到內(nèi)存有一定壓力時(shí)。

我們的 go 版本是 1.15， 內(nèi)核版本是 4.14，剛好中招！

排查結(jié)果

go 編譯器版本+系統(tǒng)內(nèi)核版本命中了 go 的 runtime gc 策略，會(huì)使得在堆內(nèi)存回收后，RSS 不下降。

問題解決解決方法

解決方法一共有兩種:

一種是在環(huán)境變量里指定GODEBUG=madvdontneed=1

這種方法可以強(qiáng)制 runtime 繼續(xù)使用 MADV_DONTNEED.（參考：https://github.com/golang/go/issues/28466）。但是啟動(dòng)了madvise dontneed 之后，會(huì)觸發(fā) TLB shootdown，以及更多的 page fault。延遲敏感的業(yè)務(wù)受到的影響可能會(huì)更大。因此這個(gè)環(huán)境變量需要謹(jǐn)慎使用！

2. 升級(jí) go 編譯器版本到 1.16 以上

看到 go 1.16 的更新說明。已經(jīng)放棄了這個(gè) GC 策略，改為了及時(shí)釋放內(nèi)存而不是等到內(nèi)存有壓力時(shí)的惰性釋放。看來 go 官網(wǎng)也覺得及時(shí)釋放內(nèi)存的方式更加可取，在多數(shù)的情況下都是更為合適的。

附：解決 pprof 看 heap 使用的內(nèi)存小于 RSS 很多的問題，可以通過手動(dòng)調(diào)用 debug.FreeOSMemory 來解決，但是執(zhí)行這個(gè)操作是有代價(jià)的。

同時(shí) go1.13 版本中 FreeOSMemory 也不起作用了（https://github.com/golang/go/issues/35858），推薦謹(jǐn)慎使用。

實(shí)施結(jié)果

我們選擇了方案二。在升級(jí) go1.16 之后，實(shí)例沒有出現(xiàn)內(nèi)存持續(xù)快速增長的現(xiàn)象。

再次用 pprof 去看實(shí)例情況，發(fā)現(xiàn)占用內(nèi)存的函數(shù)也有變化。之前占用內(nèi)存的 metrics.glob 已經(jīng)降下去了。看來這個(gè)解決方法是有成效的。

遇到的其他坑

在排查過程中發(fā)現(xiàn)的另一個(gè)可能引起內(nèi)存泄露的問題（本服務(wù)未命中），在未開啟 mesh 的情況下，kitc 的服務(wù)發(fā)現(xiàn)組件是有內(nèi)存泄露的風(fēng)險(xiǎn)的。

從圖中可以看到 cache.(Asynccache).refresher 占用內(nèi)存較多，且隨著業(yè)務(wù)處理量的增多，其內(nèi)存占用會(huì)一直不斷的增長。

很自然的可以想到是在新建 kiteclient 的時(shí)候，可能有重復(fù)構(gòu)建 client 的情況出現(xiàn)。于是進(jìn)行了代碼排查，并沒有發(fā)現(xiàn)重復(fù)構(gòu)建的情況。但是去看 kitc 的源碼，可以發(fā)現(xiàn)，在服務(wù)發(fā)現(xiàn)時(shí)，kitc 里建立了一個(gè)緩存池 asyncache 來進(jìn)行 instance 的存放。這個(gè)緩存池每 3 秒會(huì)刷新一次，刷新時(shí)調(diào)用 fetch，fetch 會(huì)進(jìn)行服務(wù)發(fā)現(xiàn)。在服務(wù)發(fā)現(xiàn)時(shí)會(huì)根據(jù)實(shí)例的 host、port、tags(會(huì)根據(jù)環(huán)境 env 進(jìn)行改變)不斷地新建 instance，然后將 instance 存入緩存池 asyncache，這些 instance 沒有進(jìn)行清理也就沒有進(jìn)行內(nèi)存的釋放。所以這是造成內(nèi)存泄露的原因。

解決方法

該項(xiàng)目比較早，所以使用的框架比較陳舊，通過升級(jí)最新的框架可以解決此問題。

思考總結(jié)

首先定義一下什么是內(nèi)存泄露：

內(nèi)存泄漏（Memory Leak）是指程序中已動(dòng)態(tài)分配的堆內(nèi)存由于某種原因程序未釋放或無法釋放，造成系統(tǒng)內(nèi)存的浪費(fèi)，導(dǎo)致程序運(yùn)行速度減慢甚至系統(tǒng)崩潰等嚴(yán)重后果。

常見場景

在 go 的場景中，常見的內(nèi)存泄露問題有以下幾種：

1. goroutine 導(dǎo)致內(nèi)存泄露

（1）goroutine 申請(qǐng)過多

問題概述：

goroutine 申請(qǐng)過多，增長速度快于釋放速度，就會(huì)導(dǎo)致 goroutine 越來越多。

場景舉例：

一次請(qǐng)求就新建一個(gè) client，業(yè)務(wù)請(qǐng)求量大時(shí) client 建立過多，來不及釋放。

（2）goroutine 阻塞

① I/O 問題

問題概述：

I/O 連接未設(shè)置超時(shí)時(shí)間，導(dǎo)致 goroutine 一直在等待。

場景舉例：

在請(qǐng)求第三方網(wǎng)絡(luò)連接接口時(shí)，因網(wǎng)絡(luò)問題一直沒有接到返回結(jié)果，如果沒有設(shè)置超時(shí)時(shí)間，則代碼會(huì)一直阻塞。

② 互斥鎖未釋放

問題概述：

goroutine 無法獲取到鎖資源，導(dǎo)致 goroutine 阻塞。

場景舉例：

假設(shè)有一個(gè)共享變量，goroutineA 對(duì)共享變量加鎖但未釋放，導(dǎo)致其他 goroutineB、goroutineC、...、goroutineN 都無法獲取到鎖資源，導(dǎo)致其他 goroutine 發(fā)生阻塞。

③ waitgroup 使用不當(dāng)

問題概述：

waitgroup 的 Add、Done 和 wait 數(shù)量不匹配，會(huì)導(dǎo)致 wait 一直在等待。

場景舉例：

WaitGroup 可以理解為一個(gè) goroutine 管理者。他需要知道有多少個(gè) goroutine 在給他干活，并且在干完的時(shí)候需要通知他干完了，否則他就會(huì)一直等，直到所有的小弟的活都干完為止。我們加上 WaitGroup 之后,程序會(huì)進(jìn)行等待，直到它收到足夠數(shù)量的 Done()信號(hào)為止。假設(shè) waitgroup Add(2), Done(1),那么此時(shí)就剩余一個(gè)任務(wù)未完成，于是 waitgroup 會(huì)一直等待。詳細(xì)介紹可以看 Goroutine 退出機(jī)制 中的 waitgroup 章節(jié)。

2. select 阻塞

問題概述：

使用 select 但 case 未覆蓋全面，導(dǎo)致沒有 case 就緒，最終 goroutine 阻塞。

場景舉例：

通常發(fā)生在 select 的 case 覆蓋不全，同時(shí)又沒有 default 的時(shí)候，會(huì)產(chǎn)生阻塞。示例代碼如下：

func main() { ch1 := make(chan int) ch2 := make(chan int) ch3 := make(chan int) go Getdata(&34;https://www.baidu.com&34;,ch1) go Getdata(&34;https://www.baidu.com&34;,ch2) go Getdata(&34;https://www.baidu.com&34;,ch3) select{ case v:=< ch1: fmt.Println(v) case v:=< ch2: fmt.Println(v) }}3. channel 阻塞

問題概述:

寫阻塞無緩沖 channel 的阻塞通常是寫操作因?yàn)闆]有讀而阻塞有緩沖的 channel 因?yàn)榫彌_區(qū)滿了，寫操作阻塞讀阻塞期待從 channel 讀數(shù)據(jù)，結(jié)果沒有 goroutine 往進(jìn)寫

場景舉例:

上面三種原因的代碼 bug 都會(huì)導(dǎo)致 channel 阻塞，這里提供幾個(gè)生產(chǎn)環(huán)境發(fā)生的真實(shí)的 channel 阻塞的例子:

lark_cipher 庫機(jī)器故障總結(jié)Cipher Goroutine 泄漏分析4. 定時(shí)器使用不當(dāng)

（1）time.after()使用不當(dāng)

問題概述：

默認(rèn)的 time.After()是會(huì)有內(nèi)存泄漏問題的，因?yàn)槊看?time.After(duratiuon x)會(huì)產(chǎn)生 NewTimer()，在 duration x 到期之前，新創(chuàng)建的 timer 不會(huì)被 GC，到期之后才會(huì) GC。

那么隨著時(shí)間推移，尤其是 duration x 很大的話，會(huì)產(chǎn)生內(nèi)存泄漏的問題。

場景舉例：

func main() { ch := make(chan string, 100) go func() { for { ch < &34;continue&34; } }() for { select { case <ch: case <time.After(time.Minute 3): } }}

（2）time.ticker 未 stop

問題概述：

使用 time.Ticker 需要手動(dòng)調(diào)用 stop 方法，否則將會(huì)造成永久性內(nèi)存泄漏。

場景舉例：

func main(){ ticker := time.NewTicker(5 time.Second) go func(ticker time.Ticker) { for range ticker.C { fmt.Println(&34;Ticker1....&34;) } fmt.Println(&34;Ticker1 Stop&34;) }(ticker) time.Sleep(20 time.Second) //ticker.Stop()}

建議：總是建議在 for 之外初始化一個(gè)定時(shí)器，并且 for 結(jié)束時(shí)手工 stop 一下定時(shí)器。

5. slice 引起內(nèi)存泄露

問題概述：

兩個(gè) slice 共享地址，其中一個(gè)為全局變量，另一個(gè)也無法被 gc；append slice 后一直使用，未進(jìn)行清理。

場景舉例：

直接上代碼，采用此方式，b 數(shù)組是不會(huì)被 gc 的。var a []intfunc test(b []int) { a = b[:3] return}

2. 在遇到的其他坑里提到的 kitc 的服務(wù)發(fā)現(xiàn)代碼就是這個(gè)問題的示例。

排查思路總結(jié)

今后遇到 golang 內(nèi)存泄漏問題可以按照以下幾步進(jìn)行排查解決：

觀察服務(wù)器實(shí)例，查看內(nèi)存使用情況，確定內(nèi)存泄漏問題；可以在 tce 平臺(tái)上的【實(shí)例列表】處直接點(diǎn)擊；也可以在 ms 平臺(tái)上的【運(yùn)行時(shí)監(jiān)控】進(jìn)行查看；

2. 判斷 goroutine 問題；

這里可以使用 1 中提到的監(jiān)控來觀察 goroutine 數(shù)量，也可以使用 pprof 進(jìn)行采樣判斷，判斷 goroutine 數(shù)量是否出現(xiàn)了異常增長。

3. 判斷代碼問題；

利用 pprof，通過函數(shù)名稱定位具體代碼行數(shù)，可以通過 pprof 的 graph、source 等手段去定位；排查整個(gè)調(diào)用鏈?zhǔn)欠癯霈F(xiàn)了上述場景中的問題，如 select 阻塞、channel 阻塞、slice 使用不當(dāng)?shù)葐栴}，優(yōu)先考慮自身代碼邏輯問題，其次考慮框架是否存在不合理地方；

4. 解決對(duì)應(yīng)問題并在測(cè)試環(huán)境中觀察，通過后上線進(jìn)行觀察；

推薦的排查工具pprof: 是 Go 語言中分析程序運(yùn)行性能的工具，它能提供各種性能數(shù)據(jù)包括 cpu、heap、goroutine 等等，可以通過報(bào)告生成、Web 可視化界面、交互式終端 三種方式來使用 pprofNemo：基于 pprof 的封裝，采樣單個(gè)進(jìn)程ByteDog：在 pprof 的基礎(chǔ)上提供了更多指標(biāo)，采樣整個(gè)容器/物理機(jī)Lidar：基于 ByteDog 的采樣結(jié)果分類展示(目前是平臺(tái)方更推薦的工具，相較于 nemo 來說)睿智的 oncall 小助手：kite 大佬研究的排查問題小工具，使用起來很方便，在群里 at 機(jī)器人，輸入 podName 即可加入我們

飛書是字節(jié)跳動(dòng)旗下先進(jìn)企業(yè)協(xié)作與管理平臺(tái)，圍繞目標(biāo)、信息與人三個(gè)維度全方位助力組織升級(jí)。一站式整合即時(shí)溝通、日歷、音視頻會(huì)議、文檔、云盤等辦公協(xié)作套件，讓組織和個(gè)人工作更高效更愉悅。飛書目前已服務(wù)包括互聯(lián)網(wǎng)、信息技術(shù)、制造、建筑地產(chǎn)、教育、媒體在內(nèi)等眾多領(lǐng)域的先進(jìn)企業(yè)。我們是飛書的Lark Core Services 團(tuán)隊(duì)，負(fù)責(zé)飛書核心的 IM 領(lǐng)域能力，包括消息、群組、用戶資料、開放能力等等。期待您的加入~

社招鏈接：

https://job.toutiao.com/s/Ne1ovPK

校招鏈接（暑期實(shí)習(xí)）

https://jobs.toutiao.com/s/NJ3oxsp

拓展知識(shí)：