問題現(xiàn)象:新增的功能,灰度部署在k8s集群的服務(wù),發(fā)現(xiàn)機(jī)器老是被打崩,因?yàn)槭腔叶?且控制了qps在100多,但是機(jī)器卻崩潰。通過對灰度機(jī)器的監(jiān)控。發(fā)現(xiàn)是內(nèi)存太高導(dǎo)致機(jī)器掛掉。此次回顧一下排查歷程。

增加GC次數(shù),從而可以通過pprof去抓取內(nèi)存使用情況：

將程序的GOGC由原先的2000改為200,從而增加GC次數(shù),然后去抓取內(nèi)存消耗情況

第一步操作完成,經(jīng)驗(yàn)證機(jī)器可以正常運(yùn)行,借助gops導(dǎo)出cpu運(yùn)行圖和內(nèi)存消耗情況
①將編譯好的linux版本的gops導(dǎo)入到目標(biāo)機(jī)器上
②執(zhí)行命令 gops 查看正在運(yùn)行的程序的pid

③執(zhí)行命令獲取cpu運(yùn)行狀態(tài) gops pprof-cpu 27
④執(zhí)行命令獲取內(nèi)存消耗情況 gops pprof-heap 27

執(zhí)行上述兩個命令后,其會生成文件在tmp目錄下：

//⑤將生成的文檔下載到本地后,分別執(zhí)行 
go tool pprof -http=:8080 cpu_profile*
go tool pprof -http=:8081 heap_profile*
//在本地生成可視化

內(nèi)存的火焰圖如下：

cpu的火焰圖如下：

通過對火焰圖的分析,可以明顯的看到j(luò)son.Marshal 和 json.Unmarshal 有明顯的占用問題。跟著火焰圖去找尋調(diào)用此處的該方法,定位到

此處就不列出runtime.Context對象的具體情況了,你可以理解為里面多處指針,多處切片。反正就是結(jié)構(gòu)體很大【PS:改天針對大結(jié)構(gòu)體出個壓測結(jié)果】

發(fā)現(xiàn)問題后更換如下代碼進(jìn)行對象copy,注意此拷貝結(jié)構(gòu)體不能有小寫字母開頭。另外建議盡量少進(jìn)行對象copy,盡可能的細(xì)化到需要copy的地方

/**
 * @Description:深拷貝數(shù)據(jù) (慎用--結(jié)構(gòu)體不能有小寫字母開頭)
 */
func DeepCopy(dst, src interface{}) error {
   var buf bytes.Buffer
   if err := gob.NewEncoder(&buf).Encode(src); err != nil {
      return err
   }
   return gob.NewDecoder(bytes.NewBuffer(buf.Bytes())).Decode(dst)
}

到此這篇關(guān)于線上問題排查之golang使用json進(jìn)行對象copy的文章就介紹到這了,更多相關(guān) golang copy內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

您可能感興趣的文章: