一榛泛、背景
公司有一個使用golang開發(fā)的采集模塊，負(fù)責(zé)調(diào)用多個外部系統(tǒng)采集數(shù)據(jù)蓖墅；最近做了一次架構(gòu)上的調(diào)整库倘，將采集模塊分成api、job兩個子模塊论矾，并部署到容器中教翩，拆分前部署在虛機(jī)上。
二贪壳、現(xiàn)象
部分采集任務(wù)在容器中的執(zhí)行時間比虛機(jī)中執(zhí)行時間要長饱亿，8倍左右，本地測試無異常
三、排查思路
1. 調(diào)用外部接口耗時過長彪笼？
只有部分任務(wù)執(zhí)行時間長钻注，懷疑容器調(diào)用那部分系統(tǒng)接口比較慢，于是在容器中curl外部接口接口杰扫，發(fā)現(xiàn)并不慢队寇，排除這個可能。
2. 程序問題章姓？
將現(xiàn)有部署在虛機(jī)中的正常運行的應(yīng)用佳遣，部署到容器中發(fā)現(xiàn)部分任務(wù)也會慢； 將部署在容器中的應(yīng)用部署到虛機(jī)后恢復(fù)了正常凡伊；懷疑是容器本身或容器網(wǎng)絡(luò)的問題零渐，一時想不到是什么原因，于是開始了慢長的定位
3. pprof
pprof是golang提供的性能分析工具之一系忙，采集模塊已經(jīng)引入pprof诵盼，首先使用它進(jìn)行排查;
(1). 在容器中安裝pprof/flamegraph1
(2). 在容器中執(zhí)行如下命令,開啟pprof的http服務(wù)
(3).輸入上述http地址
-
查看cpu profiler
pprof-1.png
> 沒有什么太大異常，只有少許執(zhí)行邏輯消耗一秒多
-
查看了top/flame graph都沒有查看到什么異常
pprof-3.png
pprof中可以查看以下幾類信息
- cpu（CPU Profiling): $HOST/debug/pprof/profile银还，默認(rèn)進(jìn)行 30s 的 CPU Profiling风宁，得到一個分析用的 profile 文件
- block（Block Profiling）：$HOST/debug/pprof/block，查看導(dǎo)致阻塞同步的堆棧跟蹤
- goroutine：$HOST/debug/pprof/goroutine蛹疯，查看當(dāng)前所有運行的 goroutines 堆棧跟蹤
- heap（Memory Profiling）: $HOST/debug/pprof/heap戒财，查看活動對象的內(nèi)存分配情況
- mutex（Mutex Profiling）：$HOST/debug/pprof/mutex，查看導(dǎo)致互斥鎖的競爭持有者的堆棧跟蹤
- threadcreate：$HOST/debug/pprof/threadcreate捺弦，查看創(chuàng)建新OS線程的堆棧跟蹤
由于跟網(wǎng)絡(luò)有關(guān)系饮寞，所以想查看下io耗時，pprof無法實現(xiàn)我的需求列吼，想到可以使用trace觀察
期間又使用go-torch采集火焰圖數(shù)據(jù)并查看幽崩，與pprof類似，感興趣的同學(xué)可自行嘗試
4. trace
trace也是go tool性能問題分析工具之一
(1) 打開trace
主要有以下幾塊：Goroutine寞钥、網(wǎng)絡(luò)阻塞慌申、同步鎖、同步阻塞等
(2) 觀察IO
一下子看到了60多秒理郑，心里一陣竊喜蹄溉，但從第一個節(jié)點開始已經(jīng)是50多秒了，仍然不知道是什么原因造成的香浩。又看了gorouting部分
看到network wait那一列耗時占比非常大类缤，心里又是一陣竊喜臼勉，基本確定是網(wǎng)絡(luò)的問題了邻吭，點擊某一個gorouting進(jìn)入grouting頁面，再根據(jù)慢的任務(wù)名稱找到相應(yīng)gorouting宴霸，點擊進(jìn)入到trace頁面
由于network占用大多數(shù)時間囱晴，連續(xù)點了靠后的幾個綠條膏蚓，發(fā)現(xiàn)最后一條語句一樣，到代碼中查看畸写，發(fā)現(xiàn)是調(diào)用redis的代碼驮瞧，于是在容器中ping redis服務(wù)器，又在虛機(jī)中ping,發(fā)現(xiàn)容器ping的響應(yīng)時間是虛機(jī)的26倍左右枯芬；想到公司的服務(wù)器分多地部署论笔，于是又查虛機(jī)、REDIS千所、容器的部署地域狂魔，發(fā)現(xiàn)虛機(jī)和REDIS在同一地域，而容器和REDIS服務(wù)器不在同一地域淫痰，這時才恍然大悟最楷，后面的解決辦法就簡單了，不在此贅述了待错；
四籽孙、總結(jié)
分析問題要從大到小，逐漸縮小范圍火俄，不能一上來就進(jìn)入細(xì)節(jié)犯建，這樣會耗時較長。開始我懷疑是虛機(jī)網(wǎng)絡(luò)問題烛占，排查了外部系統(tǒng)接口胎挎，但遺漏了REDIS，造成后面花了幾個小時仔細(xì)排查忆家。其實也是情有可原吧犹菇，這個采集模塊代碼細(xì)節(jié)我并不熟悉，對golang語言也不熟悉芽卿，只因負(fù)責(zé)這個模塊開發(fā)的同學(xué)束手無策揭芍，我是這個項目的負(fù)責(zé)人，只能趕鴨子上架了??卸例。一遇到問題称杨，我就有一種莫名的小激動，因為遇到了我未知的領(lǐng)域筷转，又有機(jī)會對技術(shù)有更深入的了解了姑原。
