From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id D2674138330 for ; Wed, 21 Sep 2016 04:01:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 13D78E0BB9; Wed, 21 Sep 2016 04:01:36 +0000 (UTC) Received: from blaine.gmane.org (unknown [195.159.176.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 428C9E0B88 for ; Wed, 21 Sep 2016 04:01:34 +0000 (UTC) Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1bmYis-0002A9-NX for gentoo-user@lists.gentoo.org; Wed, 21 Sep 2016 06:01:26 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: Kai Krakow Subject: [gentoo-user] Re: TCP Queuing problem Date: Wed, 21 Sep 2016 06:01:18 +0200 Message-ID: <20160921060118.759d94ba@jupiter.sol.kaishome.de> References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@blaine.gmane.org X-Newsreader: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) X-Archives-Salt: 952fa31f-d99b-4b16-a22c-886d9231fa5a X-Archives-Hash: 0da9905a033d38d973c8f74c80a0f959 Am Tue, 20 Sep 2016 06:08:31 -0700 schrieb Grant : > [...] > [...] > >> > >> > >> 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. If that device behaves badly in router mode by blocking just all icmp traffic instead of only icmp-echo-req, this is a good idea. You may want to bug AT&T about this problem then. It should really not block related icmp traffic. -- Regards, Kai Replies to list-only preferred.