Date: Sat, 30 Mar 2002 15:21:43 +0800 From: "Ted Striker" <tedstriker@graffiti.net> To: <lists@natserv.com> Cc: <freebsd-database@FreeBSD.ORG> Subject: Re: Raid configuration Message-ID: <20020330072143.844.qmail@graffiti.net>
next in thread | raw e-mail | index | archive | help
Well with our machine we're still in the "before" stage, so there is really no "after" to compare. About your RAID, normally the more cards you can use, the better. More cards will usually make I/O faster and also more fault tolerant. Our one card is a single point of failure, so that isn't the most optimal situation, but the best we can do right now. I believe a RAID10 would probably be faster for you, since it can read and write from more disks in parallel, versus having only one disk at a time to read or write to. Another great thing about the RAID10 is that you can lose a disk, and not lose any data or performance, while the disk is offline. ----- Original Message ----- From: Francisco Reyes <lists@natserv.com> Date: Fri, 29 Mar 2002 21:03:43 -0500 (EST) To: Ted Striker <tedstriker@graffiti.net> Subject: Re: Raid configuration > On Sat, 30 Mar 2002, Ted Striker wrote: > > > We are using RAID10 on Postgres. Also a 4 disk configuration. > > > > Since our RAID goes through only one card, it sees the whole RAID10 > > as one disk. > > How has the raid helped? > Did you do any before/after tests? > Care to share specs. > > Our current setup is a desktop with 1GB ram, Petium III 1.3Ghz CPU. > IDE disk for OS and 2 SCSI 10K rpm drives. First SCSI is database and > second logs. > > Currently there is the possibility that I may get $$ for a serious server > and I am wondering what to get. > > From what I have read so far FreeBSD with multiple CPUs does not play nice > with PostgreSQL, so that leaves out SMP. > > I am thinking 4GB ram and 4 15K rpm drives on raid 10. I guess I could do > the same thing you did and make them all one volume. > > On the current machine I rarely ever have more than 2 or 3 connections so > I have increased significantly the shared, wal, sort and vacuum buffers. > > I keep stats of many of the operations, but unfortunately I have increased > the buffers exactly when my data was expected to grow signifcantly. > > Example.. I doubled my WAL buffers, sort and vacuum buffers the same day > that I added a new table with 3 million records. > > One thing that does seem to have helped is increasing the vacuum buffers. > Although I have not timed it, but previously it seemed like it took > forever to do a vacuum full.. since increasing the buffers to 64MB it > doesn't seem to take so long. This we don't measure yet because I have > been doing the vacuum fulls manually. Not sure yet how long the vacuum > fulls would take and didn't want them to interfere with normal > processing.. specially since I have been added more data recently and my > time-frames keep changing. > > -- _______________________________________________ Get your free email from http://www.graffiti.net Powered by Outblaze To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-database" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020330072143.844.qmail>