Sean Cook wrote:
My post did say "Back in the Day" and it was around 1999 that we did
this however, then I was running unstable raid tools and they have come
a long way, and I was running 2.2 kernel.
Hey I'm sure you saw what you saw, that's not a really an issue for me.
However the link you posted was a study in "how not to do serious
hardware testing."
However, the only people I am aware of that say the performance is
better on hardware raid are hardware raid manufacturers and you... You
don't work for LSI do you? Most of the linux software folks agree with
me or take a mildly more conservative tone.
Oddly this is the first time I've ever heard of software RAID being
faster than real hardware raid... I've never seen any numbers that
remotely point to such a case in my own testing or anyone that attempted
to do real testing.
If I worked for a hardware vendor I'd hope to be getting paid more than
I do at Internet startup #5. In any case I think you're misunderstanding
the issues. Let's take a look at these links below.
Redhat Enterprise Linux (circa 2005-2006)
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-isa-en.pdf
Often the excess CPU power available for software RAID parity
calculations greatly exceeds the processing power present on a RAID
controller card. Therefore, some software RAID implementations
actually have the capability for higher performance than hardware RAID
implementations.
This is true, but does it actually mean you get more performance?
I'd argue that any self respecting RAID card has more than enough CPU
to handle saturating the slow in comparison drives. You can argue that
they do not and that might be valid. If you're right then that RAID card
does indeed suck ass.
Assuming I'm right we can say that the CPU is not a limiting factor in
either software or hardware raid. On the other hand I can say that since
I have dedicated processing power for my RAID that I don't have to worry
about spikes in load causing I/O issues as well as processing issues.
Admittedly with today's processors you'd have to be taking a gigantic
bite out of your CPU to affect your software RAID.
Mysql:
Hardware Versus Software
Some operating systems can perform software RAID. Rather than buying a
dedicated RAID controller, the operating system's kernel splits the I/O
among multiple disks. Many users shy away from using these features
because they've long been considered slow or buggy.
In reality, software RAID is quite stable and performs rather well. The
performance differences between hardware and software RAID tend not to
be significant until they're under quite a bit of load. For smaller and
medium-sized workloads, there's little discernible difference between
them. Yes, the server's CPU must do a bit more work when using software
RAID, but modern CPUs are so fast that the RAID operations consume a
small fraction of the available CPU time. And, as we stressed earlier,
the CPU is usually not the bottleneck in a database server anyway.
I understand this to mean that software raid can be just a fast as
hardware raid when there are no limiting factors. This is also true.
Notice that neither of the above said software RAID was faster only that
it could perform as well under the right conditions and save you money.
I agree with that as well.
However let's talk about a system that lives outside this perfect world
that may have RAM, CPU, and I/O contention. A system where having a
256MB cache on your RAID card turning expensive short reads and writes
into nice long reads and writes by acting as an I/O buffer eliminates
painful and expensive IO waits on your system. Things that you can
actually measure in detail using iostats from the sysstats package while
watching system load fall from 12 to .5.
In my experience having hardware raid cards has allowed me to get more
per web, db, app, or mail server than software RAID resulting in more
work for less money even with $ up charge for the raid card.
I'd be willing to use the spare Dell 2850 with five drives and a raid
card to do some testing this weekend, but someone will need to offer me
a free sushi dinner or two if I'm right. Any takers?
kashani
--
[email protected] mailing list
