From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 22:50:01 2008 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 413BD16A408 for ; Thu, 21 Feb 2008 22:50:01 +0000 (UTC) (envelope-from kris@FreeBSD.org) Received: from weak.local (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id BF1A013C447; Thu, 21 Feb 2008 22:49:59 +0000 (UTC) (envelope-from kris@FreeBSD.org) Message-ID: <47BE0016.6020407@FreeBSD.org> Date: Thu, 21 Feb 2008 23:49:58 +0100 From: Kris Kennaway User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: benjamin thielsen References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-performance@freebsd.org Subject: Re: performance degradation in 6.2 when adding a second quad core chip X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 22:50:01 -0000 benjamin thielsen wrote: > hi folks- > > we've been experiencing some interesting behavior on single quad core > computers as compared to dual quad core computers. Yes, this can happen when you run into concurrency bottlenecks in the application or in the kernel. > it appears that adding a second processor to the system (leaving it > otherwise untouched) actually decreases performance. we've got a small > rudimentary test process, built in house, that does postgresql queries > (selects) via http requests (apache2/php5). 7.0 will perform much better than 6.x on SMP workloads in general, however TCP I/O is not yet at the point where it can make efficient use of many processors (there has been a lot of work on TCP in 7.0, but it is not yet at the stage where a performance payoff will be seen with more than about 4 CPUs). This is one of the projects that we will be working on this year, so you can expect future releases to have improved concurrent TCP performance. There may be other issues, so if you like you can enable LOCK_PROFILING and obtain a trace when your workload is running (see the manpage). You should also try the ULE scheduler on 7.0. Kris