本文是武漢 gopher meetup 的分享內容整理而成，分享內容在“無人值守”的兩篇和其它社區分享中亦有提及。(也就是說你看過那兩篇，這個可以不用看了)

先來看看苦逼的開發人員

老板說：

boss

隊友說：

oom

外組同事說：

cus

底層團隊說：

under

你：

scared

業界的思路？

混口飯吃也是不容易，既然有問題了，我們還是要解決的。要先看看有沒有現成的思路可以借鑒？

Google 在這篇論文[1]里提到過其內部的線上 profile 流程：

google-profile

架構圖已經比較簡單了，線上應用暴露 profile 接口，collector 定時將 profile 信息采集到二進制存儲，由統一的在線平臺展示。

這篇論文催生了一些開源項目和創業公司，例如在?這篇文章[2]?中，對 continuous profiling 有很不錯的解釋。

cp

我們日常的 CI 和 CD 流水線可以高頻次發布線上系統，當線上有 continuous profiling 系統在運行時，每次發布我們都能夠得到實時的性能快照，并與發布前的性能做快速對照。

系統的性能問題和其它技術問題一樣，同樣是發現得越早，解決起來就越快，損失越小。

Google Cloud 上也有 profiler 相關的產品[3]，是由 Go 原先的 pprof 開發者開發的，她在文章中聲稱每分鐘對應用采集 10s 的?profile[4]，大約有 5% 的性能損失，還是可以接受的。

簡單來說，continuous profiling 帶給我們的優勢主要就是三點：

• 縮短性能問題反饋周期

• 節省服務器成本

• 改進開發者的工作流程

有了思路，再看看有沒有具體的開源產品可以參考。

相關開源產品

stackimpact

stackimpact-go 是社區比較早的開源項目了，不過只開源了 client 部分，所以 dashboard 和后端部分一直是一個謎，不過我們大概也能看出來，有這種曲線圖形式的 profile 數據，有性能衰減時能及時發現。

conprof

conprof 其實也差不多。

profefe

profefe 也差不多。

看起來思路都一樣，這個需求很簡單，我們只要找監控團隊幫忙做一套皮膚就可以了！

但監控團隊也很無奈。

mon

我們的方案

求人不如求己，我們需要定位的是抖動問題，那我們以 5s 為單位，把進程的 CPU 使用(gopsutil)，RSS(gopsutil)，goroutine 數(runtime.NumGoroutine)，用 10 大小的環形數組保存下來，每次采集到新值時，與之前多個周期的平均值進行 diff 就可以了：

ma

當波動率超過可以接受的范圍，則認為當前進程發生了資源使用抖動，那么：

• 若 CPU 抖動，從當前開始采集 CPU profile 5秒

• 若 RSS 抖動，將當前進程的 heap profile 記錄下來

• 若 goroutine 抖動，將當前進程的 goroutine profile 記錄下來

一套方案做下來，還挺簡單的。當我們收到模塊的 CPU、內存或 goroutine 數報警時，上線到相應的實例來查看即可。

實際的案例

解碼 bug

某模塊突然出現了 RSS 使用飚升，上線看之后發現自動 dump 文本的 profile 中，單個對象的 inuse_space 超過了 1GB：

//?inuse_objects:?inuse_space?[alloc_objects?:?alloc_space] 1?:?1024000000?[1?:?1024000000]??git.xxx.xxx

這是很反常的，閱讀代碼后發現在 decode 中沒有對這些情況進行一定的防御操作，有形如下面的代碼：

var?l?=?readLenFromPacket() var?list?=?make([]byte,?l)

雖然理論上 body 是可以傳 1GB 的，不過內部的 RPC 框架，還是應該對這種情況進行一些限制。

CPU 尖刺

有些在線系統是定時任務調用的，所以其訪問峰值非常不平均，在定時任務觸發后，會有一段時間 CPU 使用非常高，有了自動 CPU profile dump，就非常容易找到具體哪里使用的 CPU 很高了。

goroutine 泄露

gleak

類似這樣的 goroutine 泄露問題，也是可以很容易發現的。

deadlock(擴展)

因為我們可以采集到所有 goroutine 的棧信息，所以理論上通過遍歷我們可以發現哪些 goroutine 是持鎖的，例如下列代碼，當發生死鎖時，我們可以直接把持鎖的 goroutine dump 下來，就很容易發現死鎖了：

dlock

thread block(擴展)

當線程因為調用 cgo 等原因發生了阻塞，會造成線程數暴漲，這時候我們可以將 goroutine 和 thread profile dump 下來，進行診斷。

總結

有了自動化的工具，日子更好過了。

[1]

這篇論文:?https://research.google/pubs/pub36575/

[2]

這篇文章:?https://www.opsian.com/blog/what-is-continuous-profiling/

[3]

產品:?https://cloud.google.com/profiler/

[4]

profile:?https://medium.com/google-cloud/continuous-profiling-of-go-programs-96d4416af77b

總結

以上是生活随笔為你收集整理的几十万实例线上系统的抖动问题定位的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。