問題

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

東昌府ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

排錯(cuò)步驟

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

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

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

揭開真相

• 拖下來cap包用wireshark進(jìn)行分析,先對協(xié)議進(jìn)行統(tǒng)計(jì)，有個(gè)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)用來看這個(gè)很像是使用DCOM訪問的數(shù)據(jù)。

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

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

最后總結(jié)

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