On Sun, Jun 20, 2010 at 02:05:50PM -0500, gary clark wrote: > The below is from running MTR for windows. > > I am starting to think this is problem is intermittent.
Turn off your bittorrents :) See how the packet loss starts from the very first hop? That indicates that the issue is on your end, not the server end. The most common cause of that kind of packet loss would be link saturation. Ross > > |------------------------------------------------------------------------------------------| > > | WinMTR > statistics | > > | Host - % | Sent | Recv | Best | Avrg > | Wrst | Last | > > |------------------------------------------------|------|------|------|------|------|------| > > | 192.168.0.1 - 0 | 394 | 394 | 0 | 0 > | 16 | 0 | > > | 99.28.211.254 - 37 | 394 | 252 | 0 | 9 > | 31 | 16 | > > | dist2-vlan60.stl2mo.sbcglobal.net - 42 | 394 | 231 | 0 | 9 > | 16 | 16 | > > | bb2-g0-0.stl2mo.sbcglobal.net - 41 | 394 | 234 | 0 | 14 > | 188 | 15 | > > | 151.164.99.189 - 46 | 394 | 216 | 15 | 34 > | 234 | 15 | > > | te7-2.ccr02.ord03.atlas.cogentco.com - 48 | 393 | 206 | 15 | 21 > | 203 | 16 | > > |te0-2-0-1.ccr22.ord01.atlas.cogentco.com - 44 | 393 | 224 | 15 | 16 > | 32 | 31 | > > |te0-0-0-6.ccr22.yyz02.atlas.cogentco.com - 41 | 393 | 232 | 31 | 31 > | 47 | 31 | > > | te4-4.mpd02.yyz02.atlas.cogentco.com - 58 | 393 | 167 | 31 | 36 > | 188 | 31 | > > | 38.117.92.82 - 47 | 393 | 209 | 31 | 57 > | 844 | 31 | > > | 69-10-224-202.onx.com - 50 | 393 | 198 | 31 | 32 > | 47 | 31 | > > | 69-10-224-220.onx.com - 52 | 393 | 192 | 31 | 32 > | 47 | 31 | > > | 74-213-166-67.ultrahosting.com - 44 | 393 | 221 | 31 | 32 > | 141 | 31 | > > |________________________________________________|______|______|______|______|______|______| > WinMTR - 0.8. Copyleft @2000-2002 Vasile Laurentiu Stanimir ( > [email protected] ) > Still frustrated. > > Cheers, > Gazza > On Sun, Jun 20, 2010 at 1:13 PM, Ross Vandegrift <[email protected]> wrote: > > > On Sat, Jun 19, 2010 at 02:16:42PM -0700, cd34 wrote: > > > I did a quick run of ab, several requests came in at 3.1 seconds. I > > > don't know what sort of network they are running, but 3 seconds seems > > > very similar to an arp table rebuild in certain switches. When enough > > > machines are put on a network, it overflows the 8192 record tcam (or > > > whatever the limit is on that switch), which causes it to need to > > > rebuild the arp tree as it rediscovers. Until each machine is > > > rediscovered, they are basically 'off-net'. > > > > Such ARP table exhaustion would typically be steady-state in a > > datacenter environment - a complete and total meltdown, never > > recoverging. 3 seconds wouldn't be nearly enough time for such a > > thing to wring out. Also, TCAM isn't used for ARP entries - lots of > > things are stored in TCAM, but ARP isn't one of them. > > > > > I'd file a trouble ticket with them and let them know that you are > > > seeing packet loss into their network and that you are seeing timeouts > > > on requests going to your server and see what they say. I don't think > > > your issue is software related - I agree that it looks like it is > > > network related. > > > > If you opt to contact their support department, provide a traceroute > > from your problamtic location to the destination that shows either > > failing traceroutes or extended delays at the LAST HOP (the > > intermediate hops don't matter). MTR is a nice program for generating > > nice reports of this, but some NOCs want classic traceroute output. > > > > I don't see any evidence of a network issue, unless you were able to > > measure the 6% packet loss only at the time of HTTP impact. I'm not > > seeing any packet loss to 74.213.166.67 from my location, but it > > appears that the HTTP service is stopped now. > > > > Are you hosting on a virtualized platform? I'd be suspicious of > > platform performance issues. > > > > Ross > > > > -- > > Ross Vandegrift > > [email protected] > > > > "If the fight gets hot, the songs get hotter. If the going gets tough, > > the songs get tougher." > > --Woody Guthrie > > > > -----BEGIN PGP SIGNATURE----- > > Version: GnuPG v1.4.9 (GNU/Linux) > > > > iEYEARECAAYFAkweWlQACgkQMlMoONfO+HDgugCfWATMenhPQbC+v/F8c6yG5I+P > > NL4AnA7ZlXJy4kQpolujpZawMxzhskXD > > =1keh > > -----END PGP SIGNATURE----- > > > > > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > -- Ross Vandegrift [email protected] "If the fight gets hot, the songs get hotter. If the going gets tough, the songs get tougher." --Woody Guthrie
signature.asc
Description: Digital signature
