From owner-freebsd-performance@FreeBSD.ORG Thu Nov 18 23:29:19 2004 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DDB516A4CE for ; Thu, 18 Nov 2004 23:29:19 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 868EE43D1F for ; Thu, 18 Nov 2004 23:29:19 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 39BECA6C14; Thu, 18 Nov 2004 15:29:19 -0800 (PST) Received: from mail.trippynames.com ([127.0.0.1]) by localhost (rand.nxad.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 17860-04; Thu, 18 Nov 2004 15:29:17 -0800 (PST) Received: from [192.168.123.128] (unknown [38.113.223.82]) by mail.trippynames.com (Postfix) with ESMTP id DB78EA6C2F; Thu, 18 Nov 2004 15:29:17 -0800 (PST) In-Reply-To: <18f6019404111801471db5bbfd@mail.gmail.com> References: <18f6019404111801471db5bbfd@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 18 Nov 2004 15:29:14 -0800 To: Aaron Glenn X-Mailer: Apple Mail (2.619) cc: freebsd-performance@freebsd.org Subject: Re: I've ran out of ideas X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Nov 2004 23:29:19 -0000 > I'm pushing large files via thttpd over low-end hardware (celeron > 1.8GHz, 512MB RAM, UATA 100 drive) and, out of the box, FreeBSD > 5.3-RELEASE topped out at 40Mbps sustained. After creating a separate > partition with a much larger blocksize, it's hit 50Mbps sustained but > won't go past 54Mbps at all. Are you using thttpd+sendfile(2)? If so, I'm going to guess you've exhausted your sendfile(2) buffers. Can you run top to see what the state of your thttpd process is? I've bumped into this numerous times. If you look through arch@ there's a patch from me to change the behavior of sendfile(2) so that it returns with ENOBUFs instead of blocking when your sendfile buffers are exhausted. I would've thought that alc@'s work on sendfile(2) would've prevented this from happening, but you may have just exhausted them in which case you're getting killed by this. -sc -- Sean Chittenden