From owner-freebsd-net@FreeBSD.ORG Fri Mar 26 15:41:47 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA48A16A4CE for ; Fri, 26 Mar 2004 15:41:47 -0800 (PST) Received: from mail.dragondata.com (server2-b.dragondata.com [64.202.113.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6FD5C43D39 for ; Fri, 26 Mar 2004 15:41:47 -0800 (PST) (envelope-from toasty@dragondata.com) Received: (qmail 47364 invoked by uid 1092); 26 Mar 2004 23:42:14 -0000 Received: from toasty@dragondata.com by server2.dragondata.com by uid 82 with qmail-scanner-1.20rc3 (uvscan: v4.2.40/v4296. spamassassin: 2.60-cvs. Clear:RC:1:. Processed in 1.08346 secs); 26 Mar 2004 23:42:14 -0000 Received: from ppp045.dhcp.your.org (HELO ?199.165.179.45?) (199.165.179.45) by mail.dragondata.com with RC4-SHA encrypted SMTP; 26 Mar 2004 23:42:13 -0000 Mime-Version: 1.0 (Apple Message framework v613) Content-Transfer-Encoding: 7bit Message-Id: <23E302EC-7F7F-11D8-AA0F-000A95A8A1F2@dragondata.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: freebsd-net@freebsd.org From: Kevin Day Date: Fri, 26 Mar 2004 17:41:44 -0600 X-Mailer: Apple Mail (2.613) Subject: sendfile returning ENOTCONN under heavy load X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Mar 2004 23:41:47 -0000 I'm using thttpd on a server that pushes 300-400mbps of static content, using sendfile(2). Once the load reaches a certain point (around 800-1000 clients downloading, anywhere from 150-250mbps), sendfile() will start randomly returning ENOTCONN, and the client is disconnected. I've raised kern.ipc.nsfbufs pretty high and that hasn't made any difference. Is there any easy way to tell exactly why the sockets are being closed? I can't seem to find any obvious signs of memory exhaustion or anything. Thanks, Kevin