>>>> My web server's response time for http requests skyrockets every
>>>> weekday between about 9am and 5pm.  I've gone over my munin graphs and
>>>> the only one that really correlates well with the slowdown is "TCP
>>>> Queuing".  It looks like I normally have about 400 packets per second
>>>> graphed as "direct copy from queue" in munin throughout the day, but 2
>>>> to 3.5 times that many are periodically graphed during work hours.  I
>>>> don't see the same pattern at all from the graph of all traffic on my
>>>> network interface which actually peaks over the weekend.  TCP Queuing
>>>> doesn't rise above 400 packets per second all weekend.  This is
>>>> consistent week after week.
>>>> My two employees come into work during the hours in question, and they
>>>> certainly make frequent requests of the web server while at work, but
>>>> if their volume of requests were the cause of the problem then that
>>>> would be reflected in the graph of web server requests but it is not.
>>>> I do run a small MTU on the systems at work due to the config of the
>>>> modem/router we have there.
>>>> Is this a recognizable problem to anyone?
>>> I'm in the midst of this.  Are there certain attacks I should check for?
>> 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.

- Grant

Reply via email to