奇怪的VM高網絡接收吞吐量問題查找

問題

咱們的虛擬環境是Hyper-V ,一次在SCVMM上優化了一個VM的動態內存設置後，把SCVMM的視圖調整了一下，加了一些性能參數列。在我按照網絡吞吐量進行排序時發現，一個很普通的VM的接收吞吐量在TOP1，當時只是以爲多是瞬間的流量，沒有太在乎。後面看了幾回都在TOP5 以內，以爲問題可能不正常。

排錯步驟

• VM不太好登陸上去看，可是在Hyper-V環境，咱們有更好的方法能夠進行抓包。那就是Hyper-v網絡的高級功能，PORT Mirroring。（大概步驟就是你把VM的網卡設置爲鏡像的Source,而後在另一個專門抓包的VM的網卡上設置鏡像的Dest)，而後你就能夠抓Source 的數據包了。參考這個文章配置Hyper-v Network Port Mirroring.

• 咱們的專門抓取數據包的是個centos 7的VM ,這是一個含有工具箱的機器，能夠在多個機器上漂移，用來排錯，在設置了Port Mirroring後，咱們這個VM的第二個網卡上設置成promisc,而後抓了一小段時間的數據包。

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

揭開真相

• 拖下來cap包用wireshark進行分析,先對協議進行統計，有個dcerpc的協議佔用了75%左右的流量。

高峯大概在4Mb/s 了,平均2.5Mb/s 左右，那麼若是仔細計算下，60秒就是1分鐘的數據量大概就是150Mb,那麼10分鐘就是1.5Gb,有點嚇人，比備份系統的流量都高。

wireshark 對DCE/RPC的解釋在這裏,並且DCE/RPC的數據主要是和AD的Domain Controller進行交互，就咱們內部的應用來看這個很像是使用DCOM訪問的數據。

• 登陸到VM本地看看，發現有個深信服的ADSSO應用在這裏運行，應該就是它了。看看深信服ADSSO的介紹。

• 而後本地還有ADSSO的日誌，咱們看到大量的warning，確定無疑這個應用的問題了。

最後總結

• 沒有頭緒時須要一步步縮小範圍才能定位到問題實質，這個問題咱們只能找到問題點，雖然本身沒有辦法解決，但已經肯定到一個很是小的點了，下一步看廠商怎麼解決。曾經想反編譯下應用代碼，看看究竟是什麼邏輯，這效率過低了。後面發現代碼是VC寫的，反編譯到代碼比較麻煩