>> >> It looks like the TCP Queuing spike itself was due to imapproxy >> >> which I've now disabled. I'll post more info as I gather it. >> > >> > >> > imapproxy was clearly affecting the TCP Queuing graph in munin but I >> > still ended up with a massive TCP Queuing spike today and >> > corresponding http response time issues long after I disabled >> > imapproxy. Graph attached. I'm puzzled. >> >> >> I just remembered that our AT&T modem/router does not respond to >> pings. My solution is to move PPPoE off of that device and onto my >> Gentoo router so that pings pass through the AT&T device to the Gentoo >> router but I haven't done that yet as I want to be on-site for it. >> Could that behavior somehow be contributing to this problem? There >> does seem to be a clear correlation between user activity at that >> location and the bad server behavior. > > If that device behaves badly in router mode by blocking just all icmp > traffic instead of only icmp-echo-req, this is a good idea. You may > want to bug AT&T about this problem then. It should really not block > related icmp traffic.
Hi Kai, yesterday I switched my Gentoo router over to handling PPPoE and pings seem to be working properly now. The AT&T device is now functioning as a modem only and passing everything through. Today I'll find out if it helps with TCP Queuing and (supposedly) related http response slowdowns. - Grant
