Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I'm stuck how best to configure disk array. We have Hp P2000 G3 disk array with 24 SAS physical disks 300Gb each. We need to configure this array got 2 copies of PostgreSQL 9.2 because two different system. As we know it's recommended to store database and transaction logs(pg_xlog) files on separate disks.

So we must setup 4 logical disk:

2 for transaction logs with RAID 1
2 for database with RAID 10

Is this right scheme of distribution? Or may be it is best to just make one big RAID 10 with 4 logical disks?

enter image description here

share|improve this question

1 Answer 1

The advice to separate xlogs and the main heap/indexes is to reduce the impact of disk flushes.

This should not be necessary for higher end setups. If you care about performance you should be using a RAID controller with a persistent write-back cache (battery-backed, flash, or hybrid), in write-back caching mode. This will almost totally eliminate the cost of flushing for synchronization, and allow you to optimise for throughput alone.

This HP P2000 G3 disk array appears to come standard with 2GB of read/write cache. Make sure it's in write-back mode.

In general, for RAID controllers and disk arrays, make sure you buy the write-back cache module and use it. It doesn't matter how much it costs, it'll so massively increase the write performance of your array that you just won't believe it.

As for array layout, the best way to make these decisions is to benchmark for throughput. Use PgBench (preferably tuned to simulate your workload) and raw disk I/O benchmarks. See what array arrangements give you the best throughput and lowest sync latencies.

Remember to consider multiple disk failures. An array of 2x8 disks in RAID10 (8 disks spanned, mirrored once) is plenty big enough that double disk failures are entirely probable. Can you afford the downtime? Will you be running a streaming read-only replica or PITR slave so you don't lose data if you lose your array? Work out the failure probabilities and remember that there's a 50% chance of any double-disk failure taking out the whole array.

share|improve this answer
    
I found from specs: 2 GB transportable read/write cache per controller. Battery-free cache backup with super capacitors and compact flash. Unfortunately we could not benchmark because system is on production and we need to as quickly as possible to move. Yes, performance is our goal but the data loss is not a option. –  Yoldar-Zi Nov 30 '12 at 10:05
    
@Yoldar-Zi You found what from specs? Looks like you meant to write more... –  Craig Ringer Nov 30 '12 at 10:09
    
This disk array support only RAID levels 0, 1, 3, 5, 6, 10, 50. All type of RAIDs is slow. 0 no fault tolerance, 5, 6 slow. 50 expensive. –  Yoldar-Zi Nov 30 '12 at 10:23
    
@Yoldar-Zi 50 can also be slow, depending on workload. Expensive how, though? Most importantly, is this array's cache in write-back mode? Can it cache writes? (Test with pg_test_fsync postgresql.org/docs/current/static/pgtestfsync.html - you should get many thousand fsyncs per second). –  Craig Ringer Nov 30 '12 at 10:35
    
yes it supports cache write. And it is battery-free. –  Yoldar-Zi Nov 30 '12 at 11:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.