From owner-freebsd-questions@FreeBSD.ORG Tue Apr 25 13:42:02 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E932E16A412 for ; Tue, 25 Apr 2006 13:42:02 +0000 (UTC) (envelope-from wmoran@collaborativefusion.com) Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id F08D243D6E for ; Tue, 25 Apr 2006 13:42:01 +0000 (GMT) (envelope-from wmoran@collaborativefusion.com) Received: from vanquish.pgh.priv.collaborativefusion.com (vanquish.pgh.priv.collaborativefusion.com [192.168.2.61]) by wingspan with esmtp; Tue, 25 Apr 2006 09:42:01 -0400 id 00056413.444E2729.000092ED Date: Tue, 25 Apr 2006 09:42:00 -0400 From: Bill Moran To: Derek Ragona Message-Id: <20060425094200.06351bf6.wmoran@collaborativefusion.com> In-Reply-To: <6.0.0.22.2.20060425075640.02941d78@mail.computinginnovations.com> References: <20060424154617.9dc28c94.wmoran@potentialtech.com> <6.0.0.22.2.20060424175443.02927f48@mail.computinginnovations.com> <20060425084752.2453c0f1.wmoran@collaborativefusion.com> <6.0.0.22.2.20060425075640.02941d78@mail.computinginnovations.com> Organization: Collaborative Fusion X-Mailer: Sylpheed version 2.2.0 (GTK+ 2.8.12; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Purchasing the correct hardware: dual-core intel? Big cache? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Apr 2006 13:42:03 -0000 On Tue, 25 Apr 2006 07:59:29 -0500 Derek Ragona wrote: > If your database application is CPU bound, you may need to re-architect the > database. You may need more indexes. You may be calculating values on > queries, rather than storing calculated values. I appreciate your concern about our re-architecting, but we've already got a group focusing on the data model. My current project is to analyze the performance of the app with regard to specific hardware and make recommendations as to what hardware should be purchased for new systems. All I want is a way to track CPU cache usage so I can determine whether larger caches are worth the $$$. > There are many ways to optimize a RDBMS performance, but the first thing to > do is analyze the data model, and how the data is used. Our current data model appears to be as optimized as is reasonable. With this carefully planned data model in use, we run our test framework to load the test server environment, and find that CPU on the database server is the current bottleneck. Thus I need to find a way to speed up _that_ bottleneck. And this boils down to: How can I tell if 2M cache is enough or if larger cache sizes will improve CPU throughput, without investing in the hardware? It may boil down to this being impossible. If that's the case, I'll recommend that we purchase one of the 8M cache systems to test it out. It's a bit of an investment: http://configure.us.dell.com/dellstore/config.aspx?c=us&cs=555&l=en&oc=pe6850pad&s=biz -- Bill Moran Collaborative Fusion Inc. **************************************************************** IMPORTANT: This message contains confidential information and is intended only for the individual named. If the reader of this message is not an intended recipient (or the individual responsible for the delivery of this message to an intended recipient), please be advised that any re-use, dissemination, distribution or copying of this message is prohibited. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. ****************************************************************