Skip site navigation (1) Skip section navigation (2)

Re: Tuning PostgreSQL

From: "Alexander Priem" <ap(at)cict(dot)nl>
To: "Roman Fail" <rfail(at)posportal(dot)com>,<shridhar_daithankar(at)persistent(dot)co(dot)in>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Tuning PostgreSQL
Date: 2003-07-21 14:00:34
Message-ID: 014a01c34f90$74bc2c80$b696a8c0@APR (view raw or flat)
Thread:
Lists: pgsql-performance
That's true, certainly, and with four disks (2x18 and 2x72 or 36), I would
be able to (a) be safe and (b) split the data and WAL.

Hmmm. Seems to me that this setup would be better than one RAID5 with three
36Gb disks, wouldn't you think so? With one RAID5 array, I would still have
the data and the WAL on one volume...

Thanks for all your help so far.

Kind regards,
Alexander Priem.




----- Original Message -----
From: "Roman Fail" <rfail(at)posportal(dot)com>
To: "Alexander Priem" <ap(at)cict(dot)nl>; <shridhar_daithankar(at)persistent(dot)co(dot)in>;
<pgsql-performance(at)postgresql(dot)org>
Sent: Monday, July 21, 2003 3:45 PM
Subject: Re: [PERFORM] Tuning PostgreSQL


> > What would you guys think of not using RAID5 in that case, but just a
really
> > fast 15.000 rpm SCSI-320 disk?
>
>
> I'd say you must be able to tolerate losing all the data since your last
database backup.  Your battery backed cache, rotational speed, and transfer
rate aren't going to help at all when the drive itself degrades and corrupts
data.  If you can really only afford 3 drives, I'd have a single drive with
the OS & WAL on it, and the data on a RAID-1 mirror set using the other 2
drives.  If you need more space for data, or want your OS drives to be
mirrored - it's going to cost more.  See if you can get 2x18GB drives for
the OS and 2x73GB drives for the data.
>
> You have to consider how much headache that small amount of additional
money is going to save you (and your users) down the road.
>
> Roman
>
> -----Original Message-----
> From: Alexander Priem [mailto:ap(at)cict(dot)nl]
> Sent: Mon 7/21/2003 5:43 AM
> To: shridhar_daithankar(at)persistent(dot)co(dot)in; pgsql-performance(at)postgresql(dot)org
> Cc:
> Subject: Re: [PERFORM] Tuning PostgreSQL
>
>
>
> Thanks, i'll look further into these mount setting.
>
> I was just thinking, the server will have a (RAID) controller containing
> 128Mb of battery-backed cache memory. This would really speed up inserts
to
> the disk and would prevent data loss in case of a power-down also.
>
> What would you guys think of not using RAID5 in that case, but just a
really
> fast 15.000 rpm SCSI-320 disk?
>
> Kind regards,
> Alexander.
>
>
> ----- Original Message -----
> From: "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in>
> To: <pgsql-performance(at)postgresql(dot)org>
> Sent: Monday, July 21, 2003 2:05 PM
> Subject: Re: [PERFORM] Tuning PostgreSQL
>
>
> > On 21 Jul 2003 at 13:45, Alexander Priem wrote:
> >
> > > So where can I set the noatime & data=writeback variables? They are
not
> > > PostgreSQL settings, but rather Linux settings, right? Where can I
find
> > > these?
> >
> > These are typicaly set in /etc/fstab.conf. These are mount settings. man
> mount
> > for more details.
> >
> > The second setting data=writeback is ext3 specific, IIRC.
> >
> > HTH
> >
> > Bye
> >  Shridhar
> >
> > --
> > History tends to exaggerate. -- Col. Green, "The Savage Curtain",
stardate
> > 5906.4
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>


In response to

Responses

pgsql-performance by date

Next:From: Josh BerkusDate: 2003-07-21 16:06:10
Subject: Re: Tuning PostgreSQL
Previous:From: Roman FailDate: 2003-07-21 13:45:32
Subject: Re: Tuning PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group