>> >> 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.