On September 20, 2016 4:53:41 PM GMT+02:00, Grant <emailgr...@gmail.com> wrote: >>>>>> 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. -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
