Tell me more ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.
up vote 3 down vote favorite
3

I use Postgresql 8.4 and I wanted to know what type of RAID is mostly used for databases. I read everywhere that RAID10 is the best suited and RAID5 not a good option. ex: http://www.revsys.com/writings/postgresql-performance.html

My server is a Dell Poweredge 2950. Dell support told me that they dont have a lot of customers using RAID10. Most of times they use RAID5 + raid controller cache ON.

What do you think about that? What RAID level do you use for your database servers?

Thanks !

share|improve this question

8 Answers

up vote 6 down vote accepted

Pol,

I'd probably go with RAID10 if you have a lot of writing done to your database.

Here's a good real world case to consider... replacing a file server that has only a single 1TB HDD with a new server with four 1TB hard drives. The decision was made to go with RAID5.

Performance was NOTICIBLY slower on the new machine. It was discovered later that the server handled A LOT more writes than originally thought. The write penalty from RAID5 was pretty bad.

The correct decision in this was to go with RAID10.

share|improve this answer
That's correct, write performance on a RAID 5 is at best, and I mean at best, comparable to a single drive, if not (and usually is) slower. You should go with a RAID 10/RAID 1 configuration if you want any kind of performance. RAID 5, Slow Write, Fast Read RAID 10, Fast Write, Faster Read RAID 1, Normal Write, Faster Read RAID 0, Fastest Write, Fastest Read, but no data redundancy, you lose a disk, you lose everything. – IceMage Aug 17 '09 at 16:40
1  
That's too generic a statement. RANDOM write performance on a RAID5 is poor, whereas if you have a write workload that is a large volume of sequential writes, the performance of RAID5 exceeds RAID10. That being said, 99% of the time it's a random write workload (or a workload that's not going to take advantage of full-stripe writes on RAID5). – MikeyB Aug 17 '09 at 17:03
For database storage one important factor for performance is the 'apparent' number of spindles. In normal operation RAID5 performs like (n - 1) spindles for reads and (1 - ((n - 1) / n)) spindles for writes. RAID6 looks like (n - 2) for reads and and is even slower for writes than RAID5. In degraded mode both RAID5 and RAID6 perform horribly. RAID10 performs like (n / m) spindles for both reads and writes. – Rik Schneider Aug 17 '09 at 23:11
@Rik It will look like n spindles for random reads because of distributed parity. – Captain Segfault Aug 18 '09 at 18:18
up vote 3 down vote

The best answer depends on the profile your database fits more closely: OLTP or OLAP. To oversimplify, does your database do more writes or more reads? A database doing more writes than reads will typically perform better on raid10 than raid5 (assuming the same number of drives are used). As Karl mentioned, if your dataset (or drives) are large stay away from R5 and use R6 if R10 isn't your selection.

share|improve this answer
up vote 3 down vote

It's workload dependent and you must benchmark.

In theory, RAID 5 is slow for small writes. A big cache can mitigate this tremendously (or even make it identical in performance to RAID 1+0 for a given setup).

Often RAID 1+0 is politically difficult as the extra space is seen as wasted. Try to explain that having empty space on a RAID5 that could be used to gain performance is a different form of wasting space.

If you can't benchmark and you have the disk space already, always go with RAID 1+0. If you can't benchmark and you are forced to go to RAID5 or RAID6, make sure you clearly state in writing that RAID6 and RAID5 have the biggest performance risk for write-intensive loads. Make sure the insistence that you set it up in a manner that creates the biggest performance risk without testing first is also put in writing.

When you benchmark, make it clear to the application group doing the benchmarking how RAID5 works, the fact that the controller has cache that can mitigate the small write penalty, and that the benchmark needs to be on a data set that is identically sized to production.

Do all this in writing. Storage configuration mistakes are the most common blame game in many environments. Basically you're not going to be allowed to benchmark and you're going to have to guess, so make sure that you have the evidence that you made a best guess, or that you were told to do something contrary to best practices.

share|improve this answer
up vote 2 down vote

Please find here a performance and scaling reports, about HP Proliant DL380 G5.
the tests are based on various file systems (jfs, xfs, reiserfs, ext2 and ext3).

share|improve this answer
up vote 2 down vote

Honestly, in my experience, I don't see a difference in RAID5 over RAID10 from a data redundancy perspective. However, RAID10 offers a performance boost due to the fact that the RAID is striped. RAID 10 is basically a RAID0 and RAID1. Two RAID0 sets are mirrored (RAID1). We use RAID5 over RAID10. But we don't require the performance gain from RAID10. It just depends on your environment and what you are working with. I would recommend trying a RAID5. If it seems that performance is slower move to RAID10 and see if the performance gain helps. If you have small to medium workloads, RAID5 should do the trick.

share|improve this answer
On large arrays, I've seen RAID5/6 be larger than RAID10. The controller can read as fast as it can assemble the data into a coherent stream because one of the disks' head will always be close to the location of the data that's needed. – Karl Katzke Aug 17 '09 at 16:29
In Dell controllers R10 is made of a Stripe across mirrored pairs. If you lost 1 drive, you'd have to rebuild the entire R0 stripe - Ouch! If you lost 1 drive from both sides of the mirror you'd be S.O.L. ;) – Jeff Hengesbach Aug 17 '09 at 16:32
up vote 1 down vote

For best performance use SSDs, then R10, then 1 or 0, then 5, then 6.

share|improve this answer
1  
RAID0 gives me night terrors :o – ITGuy24 Aug 17 '09 at 15:46
1  
Why would you put raid5 over raid6? And why raid 0 over raid5/6? Backwards. – Karl Katzke Aug 17 '09 at 15:51
R0 gives me terrors too but it is faster than R5, and R6's write performance is famously bad but can have better read performance as it supports larger arrays thus more spindles. – Chopper3 Aug 17 '09 at 16:06
Karl, I think he's talking performance only. In that case RAID 0 would be faster than RAID 5/6. Not more secure, just faster. Most of us don't consider RAID 0 an option for much of anything... especially DB servers. :-) – KPWINC Aug 17 '09 at 16:07
Correct, hence the 'for best performance' bit. – Chopper3 Aug 17 '09 at 16:09
up vote 1 down vote

RAID5 is used because it's easier to setup and think about than RAID10. You don't require an even number of disks and more people are familiar with it.

In the past, we have always done RAID5 (Dell PowerEdge 2650-2950), but in our latest machine (running MS-SQL, not PostgreSQL) I tested both RAID10 and RAID5. I found that for our workload, RAID10 gave us a moderate performance increase (~10%).

If you have the time, I would suggest setting the server up both ways and running normal DB tasks (backups and restores, whatever jobs or reports you might do).

share|improve this answer
I don't believe that R5 is more or less easy to setup than R10 but it does give the best space utilisation ratio for arrays it can support. The penalty is of course write performance under load where it can be hugely beneficial moving to R1 or R10. – Chopper3 Aug 17 '09 at 15:11
As for Dell internal RAID controllers, the PERC6i(newest) is the first to support R10 - a big reason 'most' customers using internal storage used R5 (they had to). – Jeff Hengesbach Aug 17 '09 at 16:20
I think it's easier because you don't have to think about how many disks you have or how you might partition. Just make sure you have at least 3 disks. With PERC5, I remember being able to do a RAID1 and then RAID0 on top of it. I think PERC6 is the first time we've got RAID10 in one step. – Dave Aug 17 '09 at 17:03
up vote 1 down vote

SSDs don't always provide best performance. They read the data in ordered blocks, which may not be what the database needs.

When deciding what RAID and filesystem to use for a database, the important questions are:

  • How large is the dataset / drive?
  • How much money do you have?
  • Is it read-heavy or write-heavy?

If the dataset is large, i.e. > 10 TB, you will want avoid RAID5. You could lose a second drive while rebuilding the array, resulting in a total loss of data. RAID6 and RAID10 are good profiles, but be aware of the restrictions with RAID10. Also: Pick a journaled filesystem that doesn't require a regular fsck-ing; in other words, avoid ext3 and go with something like xfs... or better yet, go Solaris and use zfs. Do you have any idea how long it takes to fsck a 10tb volume?

If you have more money, you can buy an external cabinet and might get some additional speed boosts since the machine won't be trying to do system activity (logging, etc.) while reading from the dataset. You can also get a better RAID controller with more RAM and higher throughput, or faster disks. Basically, you get what you pay for.

If the data is read-heavy, you can stick to Raid10. If your data is balanced read/write or write-heavy, you'd probably better stick with raid6.

share|improve this answer
1  
SSD reads data in ordered blocks? what? Did you confuse SSD with a tape drive or something?? SSD's biggest strength is it's random access speed, which is 10 to 100 times faster than HDD! SSD is a perfect fit for database usage, the only downside is the much greater cost. But if your database is only a few tens of GB, a SSD will give you huge speedups in most cases. – davr Aug 17 '09 at 19:10
NAND Flash 101: You have a 20k block of 5 pages 4k in size. You write something to the first 4k page, then something to the next two 4k pages, and then you delete the information in the 4k page. The OS marks it as deleted, but the controller doesn't delete it -- NAND Flash can only delete entire blocks, not individual pages. Now let's say you want to write a 12k file to that block. The 8k you'll keep needs to get read into cache, then the block gets deleted, then all 20k gets written. From the OS's POV, 12k got written. From the NAND controller, 26k, doubling the time it took. – Karl Katzke Aug 17 '09 at 21:54

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.