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