From owner-cvs-src@FreeBSD.ORG Fri Jan 9 10:10:12 2004 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15A9B16A4D0 for ; Fri, 9 Jan 2004 10:10:12 -0800 (PST) Received: from root.org (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id 26A7543D46 for ; Fri, 9 Jan 2004 10:10:05 -0800 (PST) (envelope-from nate@root.org) Received: (qmail 40800 invoked by uid 1000); 9 Jan 2004 18:10:05 -0000 Date: Fri, 9 Jan 2004 10:10:05 -0800 (PST) From: Nate Lawson To: Andre Oppermann In-Reply-To: <3FFEBBC9.A42EDC25@freebsd.org> Message-ID: <20040109095640.G40628@root.org> References: <200401081740.i08He8J9063202@repoman.freebsd.org> <3FFEB449.1C32B5FD@freebsd.org><3FFEBBC9.A42EDC25@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: cvs-src@freebsd.org cc: silby@silby.com cc: src-committers@freebsd.org cc: davidxu@freebsd.org cc: cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/netinet ip_icmp.c tcp.h tcp_input.c tcp_subr.ctcp_usrreq.c tcp_var.h X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2004 18:10:12 -0000 On Fri, 9 Jan 2004, Andre Oppermann wrote: > silby@silby.com wrote: > > > > > David Xu wrote: > > >> > > >> I got following messages when I am running mysql stress test suite, > > >> and the test can not be completed. > > >> > > >> "too many small tcp packets from 128.0.0.1:20672, av. 91byte/packet, > > >> dropping connection" > > > > > > You can set net.inet.tcp.minmssoverload to a higher value than the > > > default of 1,000. I suggest trying with 2,000 as next step and see if > > > it still overloads. > > > > > > Appearently my default of 1,000 pps is fine for normal use but too low > > > for some edge cases. > > > > > > Could you check the MySQL source code if it has a setsockopt() setting > > > the TCP_NODELAY option? That would help to explain a lot. > > > > This might nerf the protection a bit, but could reduce the packet counter > > once for each socket write the local machine does? That should protect > > chatty applications, but still detect those that are just flooding data to > > a bulk service like ftp or smtp. This is exactly what I was worried about. I know of several applications that send/receive lots of small packets as a control connection, especially over localhost. Most are a sort of RPC mechanism where TCP_NODELAY is set to make sure the request gets to the server immediately and is not queued according to Nagle. > It doesn't help in this case as we don't have any control over the sender > and thus don't know whether he has set TCP_NODELAY. Perhaps you didn't understand Mike? You don't care if TCP_NODELAY is set on their side, all you care about is the packet equilibrium. If you send data in response to receiving a segment, the net equilibrium is preserved. The real behavior you want to detect is someone sending a lot of small chunks of data that the application could process as larger chunks. If the application waits until it has a full "record" before responding, you can distinguish the degenerate case by the application's response rate. > I suspect that the database(s) are setting TCP_NODELAY and do a write() > for every record they have retrieved from the query result. Yet one more > who has been fooled by the name "TCP_NODELAY". The database would be > better off and have more performance not using nodelay and let Nagle do > its work. In the case above, the small packets are coming from an ephemeral port so they are likely the query packets, not the response. But if you subtracted one from the counter each time the database responded with data, it's likely the request/response rate would be roughly constant. The database did not set TCP_NODELAY, the client did. Since the query is a small request and you need a response before you can send the next request (assuming it's not doing transaction logging), you do want TCP_NODELAY on the client. -Nate