Date: Wed, 25 Oct 2006 12:49:17 +0100 (BST) From: Alex Hayward <xelah-freebsd@xelah.com> To: stable@freebsd.org Subject: Re: Running large DB's on FreeBSD Message-ID: <Pine.LNX.4.58.0610251236560.30579@sphinx.mythic-beasts.com> In-Reply-To: <20061024115811.GA10499@hugo10.ka.punkt.de> References: <453D49D2.1010705@rogers.com> <3861E2E8-4232-4C46-8D0A-1B6079BCA07D@mac.com> <20061024115811.GA10499@hugo10.ka.punkt.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 24 Oct 2006, Patrick M. Hausen wrote: > Hello! > > On Mon, Oct 23, 2006 at 04:10:19PM -0700, Chuck Swiger wrote: > > > As for the disk configuration, using RAID-5 is one of the worst > > possible choices for a database; using multiple RAID-1 mirrors or a > > RAID-10 config would probably do a lot better in terms of performance > > and reliability. > > I second that. And I just want to add: you can easily and reliably > run this configuration in software by the means of gmirror and > gstripe. Saves you some $$ that you would have spent on a "hardware > RAID controller". And it's neither slower nor less reliable. Actually, one with a battery backed cached can be faster, especially for databases. PostgreSQL (and any database worth using) will fsync its WAL at the end of every transaction. Without a battery backed cache this will involve at least one write to disk (and, I believe, usually at least one disk rotation, so your disk rotation speed can limit your transaction rate). With a battery backed cache the write will go straight to the cache and there's no need to wait for the disk. It's also easier to get away with putting your WAL and data on one RAID 10 array. Without a battery backed cache having a separate RAID 1 array for WAL can help, because the WAL is written sequentially and having random access mixed in makes that perform badly. A 10GB database is very small, though, so IO bandwidth, seek times and the number of spindles available for reading data may not matter very much. You may also want to worry about being able to switch the array from one computer to another following a server hardware failure. Some of the fancier setups (like SANs) may even let you do this remotely (if rather expensively, and not necessary with high IO bandwidth).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.58.0610251236560.30579>