Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

WE just moved our rack to a datacenter in the building. In our rack is a blade running centos and apache for intranet stuff. When we moved to the DC, we essentially extended our LAN there via adding a cisco switch. Since moving there, our intra sites have become painfully slow.

Looking at a wireshark cap, my inexperienced eyes don't see anything that sticks out as the culprit, though it's easy to see where the delay is:

slow cap

20 seconds there on the TCP segment of reassembled PDU. And there are a lot of those that follow, but none with a delay like that. Most are ms in length.

The only thing I can think is that the switch we are using in the DC has QoS on it. That's really the only difference I can think of other than the physical location being about 300 feet further away.

Is this something QoS might do? If not, what may be some other culprits?


share|improve this question
up vote 0 down vote accepted

Severe performance problems on a LAN can caused by speed/duplex mismatch on an uplink. Can you confirm that this server and service is not the only one affected?

share|improve this answer
Well we have several machines behind that switch. a PDC and BDC one of which is also fileserv and dns, all those work fine (RDP, DNS, FILES, telnet, etc). Thanks. – stormdrain Aug 3 '11 at 16:36
that makes me think that this web site or web server is relying on something that is no longer reachable. 20 seconds sounds like a timeout value on something to me. Can you get packet capture on the web server to show what it might be reaching out to? – JakePaulus Aug 4 '11 at 0:52
I think I found the culprit. I didn't use a crossover cable to connect to the db machine, but instead used a regular cable. I will try with the right cable as soon as I can get in the DC. – stormdrain Aug 5 '11 at 17:59

Used straight through cable instead of crossover cable as needed. Traffic was still getting through, but it was taking much longer as the timeout needed to occur before finding an alternate route.

share|improve this answer
This doesn't make much sense. Unless both ends were trying to auto-crossover and kept switching the TX and RX pins at the same time? Does this happen? And, why wouldn't the same thing happen with a crossover cable? – Brad Aug 8 '11 at 16:13
I don't know the specifics of how, but that's what was happening--the connection would come up, then the delay (~20sec in above capture) was the stall waiting for the db machine. If I had to guess, which it so happens I do, I'd say the traffic was only utilizing part of the available cable--fragmenting everything, then once all the data was there (~20 seconds), it displayed the page. – stormdrain Aug 8 '11 at 16:30
That is impossible. Just for kicks, when it happens again, check your link lights and see if the link has been lost. – Brad Aug 8 '11 at 16:31
Wouldn't I have seen an issue with the link in the capture if it was the link being lost? I didn't--I scrolled fully through several captures from start to end--but wasn't specifically looking for one. And can't say for sure I'd know one if I saw one. Though wireshark has great highlighting, I don't know how much/if a link down would show. If I had to guess, which I do, I'd guess I'd see a bunch of re-connections. I didn't--but again wasn't looking for them specifically. – stormdrain Aug 8 '11 at 19:10
You would have seen a dropout of data, but that's it. – Brad Aug 8 '11 at 19:14

Your Answer


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.