一、背景
公司有一個(gè)使用golang開(kāi)發(fā)的采集模塊，負(fù)責(zé)調(diào)用多個(gè)外部系統(tǒng)采集數(shù)據(jù)；最近做了一次架構(gòu)上的調(diào)整，將采集模塊分成api、job兩個(gè)子模塊，并部署到容器中，拆分前部署在虛機(jī)上。
二、現(xiàn)象
部分采集任務(wù)在容器中的執(zhí)行時(shí)間比虛機(jī)中執(zhí)行時(shí)間要長(zhǎng)，8倍左右，本地測(cè)試無(wú)異常
三、排查思路
1. 調(diào)用外部接口耗時(shí)過(guò)長(zhǎng)？
只有部分任務(wù)執(zhí)行時(shí)間長(zhǎng)，懷疑容器調(diào)用那部分系統(tǒng)接口比較慢，于是在容器中curl外部接口接口，發(fā)現(xiàn)并不慢，排除這個(gè)可能。
2. 程序問(wèn)題？
將現(xiàn)有部署在虛機(jī)中的正常運(yùn)行的應(yīng)用，部署到容器中發(fā)現(xiàn)部分任務(wù)也會(huì)慢； 將部署在容器中的應(yīng)用部署到虛機(jī)后恢復(fù)了正常；懷疑是容器本身或容器網(wǎng)絡(luò)的問(wèn)題，一時(shí)想不到是什么原因，于是開(kāi)始了慢長(zhǎng)的定位
3. pprof
pprof是golang提供的性能分析工具之一，采集模塊已經(jīng)引入pprof，首先使用它進(jìn)行排查;
(1). 在容器中安裝pprof/flamegraph1
(2). 在容器中執(zhí)行如下命令,開(kāi)啟pprof的http服務(wù)
(3).輸入上述http地址
-
查看cpu profiler
pprof-1.png
> 沒(méi)有什么太大異常，只有少許執(zhí)行邏輯消耗一秒多
-
查看了top/flame graph都沒(méi)有查看到什么異常
pprof-3.png
pprof中可以查看以下幾類信息
- cpu（CPU Profiling): $HOST/debug/pprof/profile，默認(rèn)進(jìn)行 30s 的 CPU Profiling，得到一個(gè)分析用的 profile 文件
- block（Block Profiling）：$HOST/debug/pprof/block，查看導(dǎo)致阻塞同步的堆棧跟蹤
- goroutine：$HOST/debug/pprof/goroutine，查看當(dāng)前所有運(yùn)行的 goroutines 堆棧跟蹤
- heap（Memory Profiling）: $HOST/debug/pprof/heap，查看活動(dòng)對(duì)象的內(nèi)存分配情況
- mutex（Mutex Profiling）：$HOST/debug/pprof/mutex，查看導(dǎo)致互斥鎖的競(jìng)爭(zhēng)持有者的堆棧跟蹤
- threadcreate：$HOST/debug/pprof/threadcreate，查看創(chuàng)建新OS線程的堆棧跟蹤
由于跟網(wǎng)絡(luò)有關(guān)系，所以想查看下io耗時(shí)，pprof無(wú)法實(shí)現(xiàn)我的需求，想到可以使用trace觀察
期間又使用go-torch采集火焰圖數(shù)據(jù)并查看，與pprof類似，感興趣的同學(xué)可自行嘗試
4. trace
trace也是go tool性能問(wèn)題分析工具之一
(1) 打開(kāi)trace
主要有以下幾塊：Goroutine、網(wǎng)絡(luò)阻塞、同步鎖、同步阻塞等
(2) 觀察IO
一下子看到了60多秒，心里一陣竊喜，但從第一個(gè)節(jié)點(diǎn)開(kāi)始已經(jīng)是50多秒了，仍然不知道是什么原因造成的。又看了gorouting部分
看到network wait那一列耗時(shí)占比非常大，心里又是一陣竊喜，基本確定是網(wǎng)絡(luò)的問(wèn)題了，點(diǎn)擊某一個(gè)gorouting進(jìn)入grouting頁(yè)面，再根據(jù)慢的任務(wù)名稱找到相應(yīng)gorouting，點(diǎn)擊進(jìn)入到trace頁(yè)面
由于network占用大多數(shù)時(shí)間，連續(xù)點(diǎn)了靠后的幾個(gè)綠條，發(fā)現(xiàn)最后一條語(yǔ)句一樣，到代碼中查看，發(fā)現(xiàn)是調(diào)用redis的代碼，于是在容器中ping redis服務(wù)器，又在虛機(jī)中ping,發(fā)現(xiàn)容器ping的響應(yīng)時(shí)間是虛機(jī)的26倍左右；想到公司的服務(wù)器分多地部署，于是又查虛機(jī)、REDIS、容器的部署地域，發(fā)現(xiàn)虛機(jī)和REDIS在同一地域，而容器和REDIS服務(wù)器不在同一地域，這時(shí)才恍然大悟，后面的解決辦法就簡(jiǎn)單了，不在此贅述了；
四、總結(jié)
分析問(wèn)題要從大到小，逐漸縮小范圍，不能一上來(lái)就進(jìn)入細(xì)節(jié)，這樣會(huì)耗時(shí)較長(zhǎng)。開(kāi)始我懷疑是虛機(jī)網(wǎng)絡(luò)問(wèn)題，排查了外部系統(tǒng)接口，但遺漏了REDIS，造成后面花了幾個(gè)小時(shí)仔細(xì)排查。其實(shí)也是情有可原吧，這個(gè)采集模塊代碼細(xì)節(jié)我并不熟悉，對(duì)golang語(yǔ)言也不熟悉，只因負(fù)責(zé)這個(gè)模塊開(kāi)發(fā)的同學(xué)束手無(wú)策，我是這個(gè)項(xiàng)目的負(fù)責(zé)人，只能趕鴨子上架了??。一遇到問(wèn)題，我就有一種莫名的小激動(dòng)，因?yàn)橛龅搅宋椅粗念I(lǐng)域，又有機(jī)會(huì)對(duì)技術(shù)有更深入的了解了。
