奇怪的VM高網(wǎng)絡(luò)接收吞吐量問題查找

問題

我們的虛擬環(huán)境是Hyper-V ,一次在SCVMM上優(yōu)化了一個VM的動態(tài)內(nèi)存設(shè)置后，把SCVMM的視圖調(diào)整了一下，加了一些性能參數(shù)列。在我按照網(wǎng)絡(luò)吞吐量進(jìn)行排序時發(fā)現(xiàn)，一個很普通的VM的接收吞吐量在TOP1，當(dāng)時只是覺得可能是瞬間的流量，沒有太在意。后面看了幾次都在TOP5 之內(nèi)，覺得問題可能不正常。

排錯步驟

• VM不太好登錄上去看，但是在Hyper-V環(huán)境，我們有更好的方法可以進(jìn)行抓包。那就是Hyper-v網(wǎng)絡(luò)的高級功能，PORT Mirroring。（大概步驟就是你把VM的網(wǎng)卡設(shè)置為鏡像的Source,然后在另外一個專門抓包的VM的網(wǎng)卡上設(shè)置鏡像的Dest)，然后你就可以抓Source 的數(shù)據(jù)包了。參考這個文章配置Hyper-v Network Port Mirroring.

• 我們的專門抓取數(shù)據(jù)包的是個centos 7的VM ,這是一個含有工具箱的機(jī)器，可以在多個機(jī)器上漂移，用來排錯，在設(shè)置了Port Mirroring后，我們這個VM的第二個網(wǎng)卡上設(shè)置成promisc,然后抓了一小段時間的數(shù)據(jù)包。

  ifconfig eth2 promisc
  tcpdump -i eth2 -w client4.cap
  

揭開真相

• 拖下來cap包用wireshark進(jìn)行分析,先對協(xié)議進(jìn)行統(tǒng)計(jì)，有個dcerpc的協(xié)議占用了75%左右的流量。

高峰大概在4Mb/s 了,平均2.5Mb/s 左右，那么如果仔細(xì)計(jì)算下，60秒就是1分鐘的數(shù)據(jù)量大概就是150Mb,那么10分鐘就是1.5Gb,有點(diǎn)嚇人，比備份系統(tǒng)的流量都高。

wireshark 對DCE/RPC的解釋在這里,而且DCE/RPC的數(shù)據(jù)主要是和AD的Domain Controller進(jìn)行交互，就我們內(nèi)部的應(yīng)用來看這個很像是使用DCOM訪問的數(shù)據(jù)。

• 登錄到VM本地看看，發(fā)現(xiàn)有個深信服的ADSSO應(yīng)用在這里運(yùn)行，應(yīng)該就是它了?？纯瓷钚欧嗀DSSO的介紹。

• 然后本地還有ADSSO的日志，我們看到大量的warning，肯定無疑這個應(yīng)用的問題了。

最后總結(jié)

• 沒有頭緒時需要一步步縮小范圍才能定位到問題實(shí)質(zhì)，這個問題我們只能找到問題點(diǎn)，雖然自己沒有辦法解決，但已經(jīng)確定到一個非常小的點(diǎn)了，下一步看廠商怎么解決。曾經(jīng)想反編譯下應(yīng)用代碼，看看到底是什么邏輯，這效率太低了。后面發(fā)現(xiàn)代碼是VC寫的，反編譯到代碼比較麻煩