From owner-freebsd-stable@FreeBSD.ORG Tue Oct 24 14:36:51 2006 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C4BA116A40F for ; Tue, 24 Oct 2006 14:36:51 +0000 (UTC) (envelope-from cs@schug.net) Received: from schug.net (s0.schug.net [194.97.148.170]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5686443DAF for ; Tue, 24 Oct 2006 14:33:50 +0000 (GMT) (envelope-from cs@schug.net) Received: by schug.net (Postfix, from userid 10000) id AFFCFC5705; Tue, 24 Oct 2006 16:33:42 +0200 (CEST) Date: Tue, 24 Oct 2006 16:33:42 +0200 From: Christoph Schug To: Mike Jakubik Message-ID: <20061024143342.GB11430@voodoo.schug.net> References: <453D49D2.1010705@rogers.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <453D49D2.1010705@rogers.com> Organization: SpaceNet AG User-Agent: Mutt/1.5.11 OpenPKG/2.5 Cc: stable@freebsd.org Subject: Re: Running large DB's on FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Oct 2006 14:36:51 -0000 On Mon, Oct 23, 2006, Mike Jakubik wrote: > I am in the process of implementing a fairly large mysql server for > an even larger company, and naturally i want to use FreeBSD. The > hardware will be an HP DL385, 2 x dual-core Opterons, 16GB RAM, 7 x 15k > rpm disks in a RAID5 setup. I'm not exactly informed as to the specific > workload yet, however i know the database will have several million rows > and be larger than 10GB. Again, don't use RAID 5 for databases. Distribute your data over a bunch of table spaces on RAID 1/10 volumes. Furthermore ensure that your external storge can cope with high concurrent disk I/O. Speaking of HP we had very poor results with the cheaper storage boxes like MSA1000/MSA1500. It seems that their I/O processors can saturated very easily under concurrent I/O. If you stick to HP, choose an EVA for performance reasons. Later you can easily improve speed by adding additional disks. If you have big tables you may want to use one of the newer PostgreSQL features, Partitioning and Constraint Exclusion. See [1] for details. Disabling setproctitle() gains additional performance points, too. [1] http://www.postgresql.org/docs/8.1/static/ddl-partitioning.html#DDL-PARTITIONING-CONSTRAINT-EXCLUSION -cs