Using Perfmon to measure network issues


Running Windows 2008 Server R2.

I'm running an Application that runs on 2 servers, ServerA and ServerB. ServerA is Active and ServerB is passive. There is replication of data from ServerA > ServerB.

Recently Ive noticed that there are replication errors within the App. The vendor says this could be due to data not reaching ServerB in a timely manner.

I'd like to see if there are any NIC or network related issues. Is this possible via Perfmon? I have asked the Cisco team to check out the switchport too, but it would be useful to have some info from the server side.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Permon is actually for performance and utilization. it will not show you incase their are any errors on the network.
it will be better to ask the network team to check for errors on the switch for your port.
so incase their are any errors or network drop it will be shown on the switch logs.
neil4933Author Commented:
I am asking them :)

I just saw some Perfmon counters under TCP v4 on the server and that they maybe useful, does anyone know?
I rechecked and yes you can monitor much more in perfmon..
•Network Segment : %Broadcasts. This value will let you know how much of the network bandwidth is dedicated to broadcast traffic. Broadcasts are network packets that have been designated as intended for all machines on the segment. Often, it is this type of traffic that has a detrimental affect on the network.
•Network Segment : %Multicasts. This is a measure of the % of the network bandwidth that multicast traffic is taking. Multicast traffic is similar to the broadcast, however, there is a limited number of intended recipients. The idea was that if you can identify multiple recipients you can reduce the repetitive transmission of data. This type of transfer is used most commonly with video conferencing.
•TCP : Segments Sent/sec. This is the rate at which TCP segments are sent. This is how much information that is being sent out for TCP/IP transmissions.
•TCP : Segments Received/sec. Of course, the rate at which segments are received for the protocol.
•TCP : Segments/sec. This is just the total of the previous two counters. This is the information being sent and received. This is a general indication of how busy the TCP/IP traffic is. The segment size is variable and thus, this does not translate easily to bytes.
•TCP : Segments Retransmitted/sec. This is the rate at which retransmissions occur. Retransmissions are measured based on bytes in the data that are recognized as being transmitted before. On a Ethernet/TCP/IP network retransmissions are a fact of life. However, excessive retransmissions indicate a distinct reduction in bandwidth.
•TCP : Connection Failures. This is the raw number of TCP connections that have failed since the server was started. A failure usually indicates a loss of data somewhere in the process. Data lose can occur at many locations. This could be an indication of another device being down, or problems with the client-side configuration of the software.
•TCP : Connections Reset. This is typically a result of a timeout as opposed to an erroneous set of information. The reset results from the a lack of any information over a period of time.
•TCP : Connections Established. This counter represents them number of connections. Unlike the other two this is more and instantaneous counter of how many TCP connections are currently on the system as opposed to a count of the number of successful connections.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
IT Pros Agree: AI and Machine Learning Key

We’d all like to think our company’s data is well protected, but when you ask IT professionals they admit the data probably is not as safe as it could be.

So it will be better you configure and also ask network team to monitor on switch level. this way you will be in better complete picture.
Simply you can monitor - Start Ping between source and destination - If there is any issue then you can see some delay. else check event log,
You can get some information from it
Sushant GulatiConsultantCommented:
Well, there is something that I would like to add in and yes, certainly, the Perfmon tool is very good tool to use to check the performance monitoring.

What is this type of application and how come this APP is giving the error and when those errors are getting started?

Can you paste the APP error logs here? What is the type of data is replicated to another server?

Apart from this APP data what other pool of data is replicated from the SERVER A to SERVER B?

Is this app` using any port? If yes and than what is that port number?

Where is the data of this app` is stored? Is it on a NAS or SAN storage?

Are we replicating this data over the LAN or over the WAN? Are these servers on a single network or spread over the multiple segments?

We can use the network monitoring tool like Netmon or WireShark to monitor the application, dropping packets and data transfer over the network. Performance monitoring won't let us to choose or filter specifically. Using the network monitoring tools will help us to drill down to an extent as to what we are looking for.

Please answer the above question and you will easily know what to do.

Good Luck..!!
Do the systems have private network or are they using the same production network for replication. Way type of replication are you performing?
Look at for data collection of snmp enabled systems and graphically displaying the data.
Having your network group look at it from their point of view is probably the best solution.

However, you may need to look at other things on the servers and any SAN's involved.  We had major issues once doing backup replication.  Server group kept saying that it was due to the lack of bandwidth, it was only a 10 Mbps WAN link.  But the networking group (I part of that) noticed that during the time period where the backups failed the link utilization dropped way down.

Server group found that the SAN on the target server had a bad drive or two and once the volume of data got to a certain point it had serious problems.  Replaced the drives and everything was fine.
I agree with suresh_boga, 1st step for the network is to run a continuous ping for a day and see if there is any packet loss and the average and maximum response time.

You may want to increase the ping packet size to 1400.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Windows Server 2008

From novice to tech pro — start learning today.