RAID Performance Questions

Ivan Voras ivoras at
Thu Jan 25 22:26:55 UTC 2007

Milo Hyson wrote:

> I also ran some performance tests with a stock build of PostgreSQL 8.0
> to get a different angle on things. Two tests were run on each of the
> UDMA system drive, the RAID 5 unit, and the RAID 10 unit. The first
> tested sequential-scans through a 58,000+ record table. The second
> tested random index-scans of the same table. These were read-only tests
> -- no write tests were performed. The results are as follows:
> Unit      Seq/sec    Index/sec
> ------------------------------
> single      0.550     2048.983
> raid5       0.533     2063.900
> raid10      0.533     2093.283

58,000 records is WAY too small for any benefits to come out, unless the
records are very large ("wide"). The database and the OS will cache as
much data they can - with such a small number of records it's very
probable they will all be cached and the drives won't get any IO (and
it's lucky for you that it works this way). You can verify this
hypothesis with iostat and similar utilities.

This is also something you'll need to consider: unless you have more
data than fits in your memory, don't bother with the drives. When your
data DOES grow enough that it doesn't fit in memory (or actually - not
all of it, just the mostly accessed bits), you'll take a dramatic
performance hit which you can fix only with a large numbers of drives
(as other said - no less than 5 fast drives to get any kind of decent
performance). In that case, it's way cheaper and faster to add as much
memory as the motherboard can handle before even touching the drives.

(the above explanation holds for read-mostly loads. for write intensive
loads, go immediately to the 5+ drives option and try to avoid RAID5).

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url :

More information about the freebsd-questions mailing list