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

Re: Scaling with memory & disk planning

From: Kurt Gunderson <kgunders(at)cbnlottery(dot)com>
To:
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Scaling with memory & disk planning
Date: 2002-05-30 16:59:24
Message-ID: 3CF65A6C.5070908@cbnlottery.com (view raw or flat)
Thread:
Lists: pgsql-general
Bear in mind that I am a newbie to the PostgreSQL world but have 
experience in other RDBMSs when I ask this question:

If you are looking for the best performance, why go with a RAID5 as 
opposed to a RAID1+0 (mirrored stripes) solution?  Understandably RAID5 
is a cheaper solution requiring fewer drives for redundancy but, from my 
experience, RAID5 chokes horribly under heavy disk writing.  RAID5 
always requires at least two write operations for every block written; 
one to the data and one to the redundancy algorithm.

Is this wrong?

(I mean no disrespect)

Tom Lane wrote:

> Doug Fields <dfields-pg-general(at)pexicom(dot)com> writes:
> 
>>d) How much extra performance does having the log or indices on a different 
>>disk buy you, esp. in the instance where you are inserting millions of 
>>records into a table? An indexed table?
>>
> 
> Keeping the logs on a separate drive is a big win, I believe, for heavy
> update situations.  (For read-only queries, of course the log doesn't
> matter.)
> 
> Keeping indexes on a separate drive is also traditional database advice,
> but I don't have any feeling for how much it matters in Postgres.
> 
> 
>>a) Run everything on one 7-drive RAID 5 partition (8th drive as hot spare)
>>b) Run logs as a 2-drive mirror and the rest on a 5-drive RAID 5
>>c) Run logs on a 2-drive mirror, indices on a 2-drive mirror, and the rest 
>>on a 3-drive RAID5?
>>d) Run logs & indices on a 2-drive mirror and the rest on a 5-drive RAID 5
>>
> 
> You could probably get away without mirroring the indices, if you are
> willing to incur a little downtime to rebuild them after an index drive
> failure.  So another possibility is
> 
> 2-drive mirror for log, 1 plain old drive for indexes, rest for data.
> 
> If your data will fit on 2 drives then you could mirror both, still have
> your 8th drive as hot spare, and feel pretty secure.
> 
> Note that while it is reasonably painless to configure PG with WAL logs
> in a special place (after initdb, move the pg_xlog subdirectory and make
> a symlink to its new location), it's not currently easy to separate
> indexes from data.  So the most practical approach in the short term is
> probably your (b).
> 
> 			regards, tom lane
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
> 
> http://archives.postgresql.org
> 
> 


-- 
Kurt Gunderson
  Senior Programmer
  Applications Development
  Lottery Group
Canadian Bank Note Company, Limited
Email: kgunders(at)cbnlottery(dot)com
Phone: 
613.225.6566 x326
Fax: 
613.225.6651
http://www.cbnco.com/

"Entropy isn't what is used to be"

Obtaining any information from this message for the purpose of sending
unsolicited commercial Email is strictly prohibited.  Receiving this
email does not constitute a request of or consent to send unsolicited
commercial Email.


In response to

Responses

pgsql-general by date

Next:From: McCaffity, Ray (Contractor)Date: 2002-05-30 17:01:58
Subject: Re: erros when making examples in /src/test/examples
Previous:From: Bill GribbleDate: 2002-05-30 16:54:07
Subject: Re: erros when making examples in /src/test/examples

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