Re: Tuning PostgreSQL - Mailing list pgsql-performance

OK, another change of plans :)

ext2 seems to be a bad idea. So i'll stick with ext3. Better safe than
sorry...

About the RAID-config: Maybe RAID-10 with six disks is affordable after all.
I would have to take the smallest disks in this case, 18Gb per disk. So six
18Gb disks (15000rpm) would result in a total capacity of 54 Gb, right? This
volume would hold OS, WAL and data, but since RAID10 appears to deliver such
great performance (according to several people), in combination with the
128Mb of battery backed cache, this would be a good solution?

Hmmm. I keep changing my mind about this. My Db would be mostly 'selecting',
but there would also be pretty much inserting and updating done. But most of
the work would be selects. So would this config be OK?

Kind regards,
Alexander.


----- Original Message -----
From: "Jim C. Nasby" <jim@nasby.net>
To: "Alexander Priem" <ap@cict.nl>
Cc: "Vincent van Leeuwen" <pgsql.spam@vinz.nl>;
<pgsql-performance@postgresql.org>
Sent: Tuesday, July 22, 2003 4:33 PM
Subject: Re: [PERFORM] Tuning PostgreSQL


> On Tue, Jul 22, 2003 at 03:27:20PM +0200, Alexander Priem wrote:
> > Wow, I never figured how many different RAID configurations one could
think
> > of   :)
> >
> > After reading lots of material, forums and of course, this mailing-list,
I
> > think I am going for a RAID5 configuration of 6 disks (18Gb, 15.000 rpm
> > each), one of those six disks will be a 'hot spare'. I will just put the
OS,
> > the WAL and the data one one volume. RAID10 is way to expensive   :)
> >
> > If I understand correctly, this will give great read-performance, but
less
> > write-performance. But since this server will be equipped with an
embedded
> > RAID controller featuring 128Mb of battery-backed cache, I figure that
this
> > controller will negate that (at least somewhat). I will need to find out
> > whether this cache can be configured so that it will ONLY cache WRITES,
not
> > READS....
>
> I think the bigger isssue with RAID5 write performance in a database is
> that it hits every spindle. The real performance bottleneck you run into
> is latency, especially the latency of positioning the heads. I don't
> have any proof to this theory, but I believe this is why moving WAL
> and/or temp_db to seperate drives from the main database files can be a
> big benefit for some applications; not because of disk bandwidth but
> because it drastically cuts down the amount of time the heads have to
> spend flying around the disk.
>
> Of course, this is also highly dependant on how the filesystem operates,
> too. If it puts your WALs, temp_db, and database files very close to
> each other on the drive, splitting them out to seperate spindles won't
> help as much.
> --
> Jim C. Nasby, Database Consultant                  jim@nasby.net
> Member: Triangle Fraternity, Sports Car Club of America
> Give your computer some brain candy! www.distributed.net Team #1828
>
> Windows: "Where do you want to go today?"
> Linux: "Where do you want to go tomorrow?"
> FreeBSD: "Are you guys coming, or what?"
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend