On 15 June 2010 18:22, Janning <ml@planwerk6.de> wrote:
>> The figures are ok if the tests were done on a single drive (i.e. not
>> your RAID-0 array).
>
> Ahh, I meant raid-1, of course. Sorry for this.
> I tested my raid 1 too and it looks quite the same. Not much difference.
This is expected: a RAID-1 array (mirroring) will have the performance
of the slowest drive (or a single drive if they are equal).
>> There is no magic here - scalability of drives can be approximated
>> linearly:
>>
>> a) faster drives: 15,000 RPM drives will be almost exactly 15000/7200
>> times faster at random access
>
> ok.
(or if you are looking at raw numbers: a 15,000 RPM drive will sustain
15000/60=250 random IOs per second (IOPS); but now you are entering
magic territory - depending on the exact type of your load you can get
much better results, but not significantly worse).
>> b) more drives: depending on your RAID schema, each parallel drive or
>> drive combination will grow your speed linearly. For example, a 3-drive
>> RAID-0 will be 3/2 times faster than a 2-drive RAID-0. Of course, you
>> would not use RAID-0 anywhere serious. But an 8-drive RAID-10 array will
>> be 8/4=2 times faster than a 4-drive RAID-10 array.
>
> So RAID-10 with 4 disks is 2 times faster than a RAID-1, I got it. So as I
> need much more power I should look for a RAID-10 with 8 or more 15k RPM disks.
Yes, if you expect serious write or random IO load. To illustrate: if
you are trying to power a generic web site, for example a blog, you
can expect that most of your load will be read-only (mostly pageviews)
and except if you plan on having a really large site (many authors for
example), that your database will largely fit into RAM, so you don't
have to invest in disk drives as it will be served from cache. On the
other hand, a financial application will do a lot of transactions and
you will almost certainly need good storage infrastructure - this is
where the 250 IOPS for a 15000 RPM drive estimates come into play.
> thanks very much for your help.
> It gave me a good idea of what to do. If you have further recommendations, I
> would be glad to here them.
I can point you to a dedicated mailing list: pgsql-performance @
postgresql.org for questions about performance such as yours.