From owner-freebsd-performance@FreeBSD.ORG Thu Feb 21 22:39:37 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 0783816A404 for ; Thu, 21 Feb 2008 22:39:37 +0000 (UTC) (envelope-from bthielsen@safarivideonetworks.com) Received: from smtp.ltn.lvc.com (static-66-14-195-72.bdsl.verizon.net [66.14.195.72]) by mx1.freebsd.org (Postfix) with ESMTP id A360613C4F9 for ; Thu, 21 Feb 2008 22:39:36 +0000 (UTC) (envelope-from bthielsen@safarivideonetworks.com) Received: from localhost (localhost [127.0.0.1]) by macgyver.ltn.lvc.com (Postfix) with ESMTP id 5E5F26A0C30 for ; Thu, 21 Feb 2008 13:21:28 -0500 (EST) X-Virus-Scanned: Debian amavisd-new at macgyver.ltn.lvc.com Received: from macgyver.ltn.lvc.com ([127.0.0.1]) by localhost (macgyver.ltn.lvc.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id WsnpXs3NiYzz for ; Thu, 21 Feb 2008 13:21:23 -0500 (EST) Received: from heliax.ltn.lvc.com (heliax.ltn.lvc.com [10.10.101.200]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by macgyver.ltn.lvc.com (Postfix) with ESMTP id B980E6A0C2F for ; Thu, 21 Feb 2008 13:21:23 -0500 (EST) Message-Id: From: benjamin thielsen To: freebsd-performance@freebsd.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Thu, 21 Feb 2008 13:21:23 -0500 X-Mailer: Apple Mail (2.919.2) Subject: 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:39:37 -0000 hi folks- we've been experiencing some interesting behavior on single quad core computers as compared to dual quad core computers. 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). here is a small data set from what we've seen so far: a user is one iteration of a curl statement and values listed in the cpu columns are average time before the page returns, in seconds. users 1 cpu 2 cpu ------------------------------- 60 2.48 2.18 80 3.34 2.72 100 4.18 5.34 120 9.48 15.61 140 13.2 46.16 160 26.28 66.99 we're confident that nothing else has changed other than the addition of the chip, so i'm hoping for some insight on where we might look for clues. the above results used 6.2-RELEASE. we've started the same test using 7.0-RC2 and are seeing similar response times with both processors in place. next on our list is doing a single processor iteration of the 7.0-RC2 test to corroborate that data, followed by a local test to query pg more directly, removing apache and friends from the equation, in hopes of getting some clarity. below are the basics of this configuration - this is a new list for me, so i've been conservative, but i'm happy to provide as much detail as is helpful. computer: dell poweredge 2900 xeon quad core 2 ghz / 1333 mhz bus speed / 2 x 6mb l2 cache 4 gb 667 mhz memory all of the software has been installed via ports, the 6.2 kernel is a custom kernel with (i believe) mostly rudimentary changes and support for the perc6 disk controller (that became available in 7) added, and the 7.0 kernel contains the same changes as the 6.2 kernel, excluding the custom perc6 support. thanks! -ben