>>>>> My web server's response time for http requests skyrockets every
>>>>> weekday between about 9am and 5pm.  I've gone over my munin graphs
>>>>> the only one that really correlates well with the slowdown is "TCP
>>>>> Queuing".  It looks like I normally have about 400 packets per
>>>>> 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.
>>>>> don't see the same pattern at all from the graph of all traffic on
>>>>> network interface which actually peaks over the weekend.  TCP
>>>>> 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
>>>>> certainly make frequent requests of the web server while at work,
>>>>> 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
>>>>> I do run a small MTU on the systems at work due to the config of
>>>>> 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
>>> 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.
>>- Grant
> Things to check for:
> Torrent or other distributed downloads.
> Download program with multiple download threads

There sure shouldn't be anything like that running either on the
server or in the office.  Is there a good way to find out? Maybe
something that would clearly indicate it?

> Maybe another proxy running? Esp. as you saw this also with imapproxy.

nginx acts as a reverse proxy to apache2 but that's a pretty common
config.  Nothing else that I know of.

- Grant

Reply via email to