Re: H/W RAID 5 on slower disks versus no raid on faster HDDs

Mallah,

I agree with Chris. The fastest is to have an in
memory database.

Raid 0 (striping) will speed up both reading and
writing since you have more available disk I/O
bandwidth.

SCSI320 in theory is twice as fast as SCSI160. But the
bottleneck will be the throughput of the individual
disks. 15,000 rpm of course will be faster than 10,000
rpm. More interesting then the rpm numbers itself are
seek time and transfer rate.

In a production environment I would always favor some
kind of error protection. Either RAID 5 or RAID 1
(mirroring). A hardware RAID controller is faster than
software RAID.

For pure speed raw devices would be faster then file
systems. However, PostgeSQL currently does not support
them.

Given your 2 choices b) should be faster.
a) 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI
controller + H/W Raid 5
b) 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI and no
RAID

Option b) can be improved by using striping. Save your
money on the SCSI Ultra320 since the disk can’t
transfer enough data anyway and buy more memory instead.

And finally good application design has a greater
impact on performance than a little faster hardware.

Regards,
Nikolaus Dilger

On Thu, 21 Nov 2002, Chris Ruprecht wrote:

>
> raid 0 (striping) spreads the load over multiple
> spindels, the same way raid 5
> does. but raid 5 always needs to calculate parity and
> write that to it's
> parity drive.
>
> RPM isn't that critical, a lot depends on the machine,
> the processor and the
> memory (and the spped with which the processor can get
> to the memory). I have
> recently tested a lot of systems with some database
> benchmarks we wrote here
> at work. We're not running Postgres here at work,
> sorry, these benchmarks are
> of no use to Postgres ...
> We we found is that a lot depends on motherboard
> design, not so much on drive
> speed. We got to stages where we allocated 1.8 GB of
> RAM to shared memory for
> the database server process, resulting in the entire
> database being sucked
> into memory. When doing reads, 100% of the data is
> coming out the that
> menory, and drive speed becomes irrelevant.
>
> From tests I did with Postgres on my boxes at home, I
> can say: The more shared
> memory you can throw at the server process, the
better.
> Under MacOS X I
> wasn't able to allocate more than 3 MB, Under Linux, I
> can allocate anything
> I want to, so I usually start up the server with 256
> MB. The difference? A
> process which takes 4 minutes under Linux, takes 6
> hours under MacOS - same
> hardware, same drives, different memory settings.
>
> Best regards,
> Chris
>
> On Thursday 21 November 2002 12:02, you wrote:
> > Thanks Chris,
> >
> > does raid0 enhances both read/write both?
> >
> > does rpms not matter that much?
> >
> > regds
> > mallah.
> >
> > On Thursday 21 November 2002 22:27, you wrote:
> > > RAID 5 gives you pretty bad performance, a
slowdown
> of about 50%. For
> > > pure performance, I'd use the 3 18 GB drives with
> RAID 0.
> > >
> > > If you need fault tolerance, you could use RAID
0+1
> or 1+0 but you'd need
> > > an even number of drives for that, of which half
> would become 'usable
> > > space'.
> > >
> > > Best regards,
> > > Chris
> > >
> > > On Thursday 21 November 2002 11:45, you wrote:
> > > > Hi folks,
> > > >
> > > > I have two options:
> > > > 3*18 GB 10,000 RPM Ultra160 Dual Channel SCSI
> controller + H/W Raid 5
> > > > and
> > > > 2*36 GB 15,000 RPM Ultra320 Dual Channel SCSI
and
> no RAID
> > > >
> > > > Does anyone opinions *performance wise* the
pros
> and cons of above
> > > > two options.
> > > >
> > > > please take in consideration in latter case its
> higher RPM and better
> > > > SCSI interface.
> > > >
> > > >
> > > >
> > > > Regds
> > > > Mallah.
>
> --
> Network Grunt and Bit Pusher extraordinaire
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> <a
href="http://mail.dilger.cc/jump/http://www.postgresql.org/users-lounge/docs/faq.html">http://www.postgresql.org/users-lounge/docs/faq.html</a>