2

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?

Thanks.

stormdrain
  • 1,439
  • 7
  • 28
  • 52

2 Answers2

0

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?

JakePaulus
  • 2,347
  • 16
  • 17
  • 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 03 '11 at 16:36
  • 1
    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 04 '11 at 00: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 05 '11 at 17:59
0

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.

stormdrain
  • 1,439
  • 7
  • 28
  • 52
  • 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 08 '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 08 '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 08 '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 08 '11 at 19:10
  • You would have seen a dropout of data, but that's it. – Brad Aug 08 '11 at 19:14
  • 10-4, thanks. Maybe next time I'm in the datacenter, I'll hook up the other cable again just to see what the lights do. – stormdrain Aug 08 '11 at 19:16