From owner-freebsd-current@FreeBSD.ORG Wed Oct 3 20:47:50 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 6D42B106567A; Wed, 3 Oct 2012 20:47:50 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mx1.freebsd.org (Postfix) with ESMTP id 1BEB88FC12; Wed, 3 Oct 2012 20:47:49 +0000 (UTC) Received: by obbwc20 with SMTP id wc20so8894318obb.13 for ; Wed, 03 Oct 2012 13:47:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N2OoG9ZTWGxkBRNoXbRULHsHN0cV/MrtqSiNO8L24sY=; b=BD2TaC45n5mgF3UycvZcgxRFCJnTGw1e8G36fSG29hBOkjJ5yMrMqiOGLkBZH0XlEM ibz0z5osp/lhrQlhG8bGG6yw6s9wAd0FVxmnxZ3hYasnQYqUxDoWb4fjgJfBvRlMlLFM f2WvZOiy/p1V/Ey1afahWNDK/37OFjbT4NYQE7L0OwoUs305J9yE1Nu7vHwaQUA1jBaF ftET3VmW9AqfEFzLmrk5ImeRPXGkkQtNMOhEYjEmR3br/fbgmjtuS+6srxItUZaUfwvf KeDSPGp7Axz9pQXS076d9lteumzoAPOVug2IOWPbW8l8bmw1XsJCpRB3XbOoH1BSGJZ3 Sr+w== MIME-Version: 1.0 Received: by 10.182.218.37 with SMTP id pd5mr2594898obc.24.1349297269310; Wed, 03 Oct 2012 13:47:49 -0700 (PDT) Received: by 10.76.142.201 with HTTP; Wed, 3 Oct 2012 13:47:49 -0700 (PDT) In-Reply-To: References: <03e101cda197$326dc240$974946c0$@org> Date: Wed, 3 Oct 2012 13:47:49 -0700 Message-ID: From: Garrett Cooper To: Adrian Chadd Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd@chrysalisnet.org, freebsd-current@freebsd.org Subject: Re: sysctl kern.ipc.somaxconn limit 65535 why? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Oct 2012 20:47:50 -0000 On Wed, Oct 3, 2012 at 1:03 PM, Adrian Chadd wrote: > Hi, > > somaxconn is the connection queue depth. If it's sitting at a couple > hundred thousand then something else is going crazily wrong. > > I understand your frustration, but there's a lot of instances where > the application just isn't doing things "right" and the OS tries to > hide it as much as psosible. Blowing out somaxconn to chew up a whole > lot of resources seems a bit silly. I'd rather investigate why the > userland application is not servicing the connect queue often enough. > > I've written network services that supported tens of thousands of new > TCP connections a second on a LAN and I never once had to bump > somaxconn past 32767. I'm not saying that it won't apply to your > scenario, I'm just trying to explain that there's likely more going > on. Or the TTL of TCP connections might be too high for the volume of connections received. Someone else on net@ reported that changing this value to more aggressively reap sockets improved performance greatly (at the cost that more connections potentially needing to be reestablished and/or getting dropped on the floor if things go too high volume). But yeah... the listen(2) queue might be too high, or the application might be accept(2)'ing too much and thus the queue is backing up too much. I was merely providing the pointer to "why" things are the way they are. Thanks, Garrett "so many knobs, so little time" Cooper