Am 20.09.2016 um 21:52 schrieb Grant:
>>>>>>>> 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.
>>>>> - 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
>> Any way to find out between which hosts/servers those connections are for?
>> That might help in locating the cause.
>> Eg. which of your desktops/laptops inside your network and where they are 
>> trying to connect to.
> The spikes are taking place on my remote server but they seem to
> roughly coincide with user activity within my own network.  My
> technical knowledge of networking internals is weak.  Does anyone know
> which tool will tell me more about the connections that are causing
> the TCP Queuing spikes?
> - Grant

wireshark or whatever it is called at the moment?

Reply via email to