From owner-freebsd-performance@FreeBSD.ORG Thu Dec 23 21:11:22 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 78B7716A4CE for ; Thu, 23 Dec 2004 21:11:22 +0000 (GMT) Received: from mail.trippynames.com (mail.trippynames.com [38.113.223.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5904E43D45 for ; Thu, 23 Dec 2004 21:11:22 +0000 (GMT) (envelope-from sean@chittenden.org) Received: from localhost (localhost [127.0.0.1]) by mail.trippynames.com (Postfix) with ESMTP id 0F080A6C7E; Thu, 23 Dec 2004 13:10:56 -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 20313-02; Thu, 23 Dec 2004 13:10:45 -0800 (PST) Received: from [192.168.102.100] (dsl231-047-005.sea1.dsl.speakeasy.net [216.231.47.5]) by mail.trippynames.com (Postfix) with ESMTP id 0CE23A6C27; Thu, 23 Dec 2004 13:10:44 -0800 (PST) In-Reply-To: <7632915A8F000C4FAEFCF272A880344165164F@Ehost067.exch005intermedia.net> References: <7632915A8F000C4FAEFCF272A880344165164F@Ehost067.exch005intermedia.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <298151B6-5527-11D9-B830-000A95C705DC@chittenden.org> Content-Transfer-Encoding: 7bit From: Sean Chittenden Date: Thu, 23 Dec 2004 13:11:07 -0800 To: "Jeff Behl" X-Mailer: Apple Mail (2.619) cc: freebsd-performance@freebsd.org Subject: Re: %cpu in system - squid performance in FreeBSD 5.3 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, 23 Dec 2004 21:11:22 -0000 > As a follow up to the below (original message at the very bottom), I > installed a load balancer in front of the machines which terminates the > tcp connections from clients and opens up a few, persistent connections > to each server over which requests are pipelined. In this scenario > everything is copasetic: Interesting... I wonder what the lock contention path is between the VM and network stack. Has anyone else noticed this in their testing? Did you try a post-5.3 release or not? rwatson@ just MFC'ed a bunch of network locking fixes to RELENG_5, but none-stand out in my mind as being something that'd potentially fix your issue. Actually, he probably knows better than anyone what this could be. Some of the post RELENG_5_3 commits by alc@ could explain this, however, and is why I ask what the specific version/build time is for your release. -sc -- Sean Chittenden