2

We have moved a web application with an Oracle database to a new server because the old one was dying. The old server had two mirrored hard discs plus a separate non-mirrored SSD for the Oracle datafiles (without redo and undo log). The new server has almost the same configuration except there are now two SSDs to have them mirrored as well.

Unfortunately, the random write performance of the software RAID-1 with SSDs was very poor. During the night when a large amount of data is merged into the database the web application almost stopped working because simple insert operations like adding a log entry took 20 seconds or more. The RAID-1 simply could not keep up with Oracle's write requests caused by the nightly jobs (random access to the datafiles).

I've then reverted the configuration to the old one: no RAID but just a single SSD for the datafiles. Now the performance problems are gone, the web application is snappy at all times and the nightly jobs are about 10 times faster than with the RAID (and about the same as on the old server).

How can the software RAID possibly be at least 10 times slower than the same drive without a RAID?

Hardware:

  • Intel Xeon E3-1245 V2 @ 3.40GHz
  • 32 GB RAM
  • 2 x Seagate Constellation ES.2 ST33000650NS
  • 2 x INTEL SSDSC2BW240A4

Commands to setup the RAID:

# mdadm –-create –-name=3 /dev/md/3 --level=raid1 --raid-devices=2 /dev/sda1 /dev/sdb1
# mkfs.ext4 /dev/md3

BTW: I can't run any experiments on the new server as we had been under pressure to set it productive (the old one was dying).

Improve this question
3
  • have you benchmarked the drives in both configurations? "web application is snappy at all times and the nightly jobs are about 10 times faster" sounds a bit subjective…
    – user83664
    Sep 26, 2013 at 17:30
  • sorry, all three configurations: you'd need to show that both drives function the same on their own…
    – user83664
    Sep 26, 2013 at 17:36
  • Note that mdadm does not support TRIM. One should expect write performance to degrade over time. However, since it was a new setup, I doubt this was your problem.
    – Swoogan
    Oct 16, 2014 at 16:37

3 Answers 3

Reset to default
1

You've got enough money to pay for Oracle but not enough money for a test environment?

No answer (it's a bit long for a comment though) but some observations:

SSDs lie about their physical block size - this is actually the erase block size - which is huge.

Most disks also lie about their geometry (so you can format them from MS-DOS) - but this really hurts the performance of data striping RAID levels (but I wouldn't have expected too much impact on mirroring).

You've not shown us how they were partitioned nor what journalling you have configured.

You need to tell ext about RAID config - although again IIRC this is more of an issue for striping than mirroring.

Write operations on a mirror will never be faster (potentially up to 2x slower although more often its in the region of 20%) than to a single disk.

The problem with SSDs is write wear. In a mirror it's unusual for spinning rust disks, even from the same batch, to fail at the same time. OTOH its massivley more probable that 2 SSDs will fail at the same time. One solution is to deliberately stagger the lifespan of the disks. But if I were setting a machine with this hardware mix I'd have used mdadm to configure hybrid storage - mirror sets between SSD and HD.

I suspect that the problem is at the filesystem tier - if it were not in production, then I'd suggest giving Oracle access to the mirror device as a raw partition and checking the performance.

Improve this answer
1
  • Thanks for your suggestions. The disk has a single partion covering half of the disk. The rest isn't currently used. Journaling? Whatever ext4 uses. BTW: We have a test system. But it matches the old server's configuration, i.e. it has a single SSD.
    – Codo
    Sep 26, 2013 at 14:06
1

I guess data alignment issues. Every level (partition, RAID, filesystem) has to start at a supercell boundary. If not, every erase cycle (the worst part of Flash memory technology) would effectively be duplicated.

There's an online tool to calculate alingments, described on the OCZ forum. It might help.

Improve this answer
0
0

Redhat does not recommend RAID 1 w/ SSD and mdadm:

During the initialization stage of these RAID levels, some RAID management utilities (such as mdadm) write to all of the blocks on the storage device to ensure that checksums operate properly. This will cause the performance of the SSD to degrade quickly.

Chapter 21. Solid-State Disk Deployment Guidelines

Similar concerns are voiced elsewhere:

TRIM ( https://en.wikipedia.org/wiki/TRIM ) isn't supported with RAID on SSD today on hardware controllers and most distributions of linux don't support TRIM on RAID out of the box if you're doing software RAID, so you're going to see performance plummet like a rock after you do one pass of writes on the disk. In many RAID configurations, you're going to zero-write the entire disk when formatting it, so performance is going to suck from the get-go.

https://news.ycombinator.com/item?id=4266119

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .