Shulou(Shulou.com)06/01 Report--

problem

Our virtual environment is Hyper-V. After optimizing the dynamic memory settings of VM one at a time on SCVMM, we adjust the view of SCVMM and add some performance parameters. When I sorted by network throughput, I found that a very common VM receive throughput in TOP1, I just thought it might be instantaneous traffic at that time, and I didn't care much about it. After looking at it several times, it is all within the TOP5, and I think the problem may not be normal.

Troubleshooting steps

VM is not easy to log in to look at, but in the Hyper-V environment, we have a better way to grab the package. That's the advanced function of the Hyper-v network, PORT Mirroring. (the approximate step is that you set the VM Nic to the mirrored Source, and then set the mirrored Dest on another VM Nic that specializes in grabbing packets.) then you can grab Source packets. Refer to this article to configure Hyper-v Network Port Mirroring.

Our VM that specializes in grabbing data packets is a centos 7 VM, which is a machine with a toolbox that can drift on multiple machines to arrange errors. After setting Port Mirroring, our VM's second network card is set to promisc, and then grabs the packet for a short period of time.

Ifconfig eth2 promisctcpdump-I eth2-w client4.cap uncover the truth and drag down the cap package for analysis with wireshark. First, the protocol is counted. A dcerpc protocol takes up about 75% of the traffic.

The peak is probably in 4Mb/s, and the average 2.5Mb/s is about, so if you calculate carefully, 60 seconds is one minute of data volume is about 150Mb, then 10 minutes is 1.5Gb, which is a bit scary and higher than the traffic of backup system.

Wireshark's interpretation of DCE/RPC is here, and DCE/RPC 's data is mainly interacting with AD's Domain Controller, which is very similar to data accessed by DCOM in terms of our internal applications.

Log in to VM locally and find a convincing ADSSO application running here. This should be it. Take a look at the introduction of convincing ADSSO.

Then there are local ADSSO logs, we see a lot of warning, there is no doubt about the problem of this application. Finally, it is concluded that when there is no clue, we need to narrow the scope step by step in order to locate the essence of the problem. We can only find the point of the problem. Although we have no way to solve it, it has been determined to a very small point. The next step is to see how the manufacturer will solve it. Once wanted to decompile the application code to see what the logic is, which is too inefficient. Later, it was found that the code was written by VC, so it was troublesome to decompile it into code.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.