Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Our 2008 server began to work very slowly within 2 weeks. Our web sites (iis 7.5) are loading very slowly and sometimes its freezing. We began testing with wireshark and saw that our packets are lost during transmission. The client demands the same packets several times, please check below.

(CLIENT): 11 3.492500 Client Server TCP 54 61220 > http [ACK] Seq=316 Ack=5521 Win=66240 Len=0 (SERVER) : 12 3.495204 Server Client TCP 1434 [TCP Previous segment lost] [TCP segment of a reassembled PDU]

(CLIENT):13 3.495225 Client Server TCP 66 [TCP Dup ACK 11#1] 61220 > http [ACK] Seq=316 Ack=5521 Win=66240 Len=0 SLE=6901 SRE=8281

(SERVER) :*14 3.604038 Server Client TCP 1434 [TCP segment of a reassembled PDU]

(CLIENT):*15 3.604062 Client Server TCP 66 [TCP Dup ACK 11#2] 61220 > http [ACK] Seq=316 Ack=5521 Win=66240 Len=0 SLE=6901 SRE=9661

(SERVER) :*16 3.606074 Server Client TCP 1434 [TCP Previous segment lost] [TCP segment of a reassembled PDU] ...

(CLIENT):*23 3.714810 Client Server TCP 74 [TCP Dup ACK 11#6] 61220 > http [ACK] Seq=316 Ack=5521 Win=66240 Len=0 SLE=11041 SRE=16561 SLE=6901 SRE=9661

(SERVER) :*24 3.718211 Server Client TCP 1434 [TCP Fast Retransmission] [TCP segment of a reassembled PDU]

We cehcked the frames in detail and saw that majority of the errors are "IP checksum offload errors" . when we disable "Checksum offload" from our network adapter, then we began to receive lots of "suspected transmission" and server is still slow. Interesting thing is in one of our IP's in our server we are not receiving this error, and the web sites using that IP is rapid enough.

Do you have any idea what is going on?

share|improve this question
    
IP checksum errors normal when you have ToE because the checksum isn't calculated until the card does so and sends the packet. The sending machine never gets to see the checksum, and thus Wireshark tosses and error. –  Chris S Jun 18 '12 at 14:06
    
Sounds like you've got packet loss problems. Do a trace route to a "far destination" (purposely pick an IP on another continent if possible). Then send a dozen or three pings to each of the IPs along the route, figure out where the loss is occurring and do your best to fix that (if it's yours, you'll have to fix it; otherwise notify your ISP or the network operator). –  Chris S Jun 18 '12 at 14:08
    
Network congestion? What does your networking gear tell you/ –  HopelessN00b Genius of network Jun 18 '12 at 14:09
    
Hi Chris, thank you for reply. I made pathping test and saw that sometimes we are losing 10-15% of our packets in one server of our ISP. But this does not explain why its occuring in only some Ip's. Also we are using 3 more servers in the same location and we are not encountering this problem. –  Kamil Ovacık Jun 19 '12 at 9:29
    
Hi Hopeless,How can I check whether there is network congestion ? and what to do to avoid it ? –  Kamil Ovacık Jun 19 '12 at 9:31
add comment

1 Answer

Many TCP performance problems come down to very simple issues with consistent packet loss; even loss rates that appear small (0.5%) can cause significant problems for TCP.

Please download winmtr and install it on your Windows 2008 server; this is a free utility that will track packet loss per hop. Run this against destination(s) where you experience throughput problems. Your goal is to baseline consistent packet loss for at least 10 or 15 minutes; sometimes I will let it run for hours to catch intermittent packet loss at a hop. When you see a hop where packet loss starts, and continues on all hops afterwards, that is the place to start looking for issues.

Example:

winmtr

In this trace, packet loss starts at the first hop in the network (10.27.136.1), so the link on the window's machine's ethernet card / router is a possible cause; congestion at the first hop is another possible cause.

Keep in mind that winmtr relies on ICMP error messages from routers, so

  • Ethernet switches do not show up as an explicit hop in the path, but still could contribute to packet loss
  • Some routers rate-limit (or even filter) ICMP error messages, so hops that don't show consistent packet loss after them may just be hitting their rate limit (or configured to filter ICMP errors)
  • Firewalls may prevent visibility through them
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.