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?
