| 1 |
-----BEGIN PGP SIGNED MESSAGE----- |
| 2 |
Hash: SHA1 |
| 3 |
|
| 4 |
kashani wrote: |
| 5 |
> Sean Cook wrote: |
| 6 |
> > Redhat In their manual: |
| 7 |
> |
| 8 |
>> "With today's fast CPUs, Software RAID performance can excel against |
| 9 |
>> Hardware RAID." |
| 10 |
>> |
| 11 |
>> As I stated before, it depends on where your bottleneck is... if you |
| 12 |
>> are not cpu bound, software raid is great! and will boost IO through |
| 13 |
>> put on comparable hardware. If you are already CPU bound, forget |
| 14 |
>> software raid, it will degrade your system to a crawl... |
| 15 |
> |
| 16 |
> |
| 17 |
> Badly done tests circa 1998 without any sort of methodology, mention of |
| 18 |
> cluster sizes, etc is proof than any idiot can make a computer slower. |
| 19 |
> |
| 20 |
> I'll argue that a fully supported hard raid card is always superior |
| 21 |
> to a software raid by it's very nature, having local I/O cache and a |
| 22 |
> dedicated chip. However there are definitely workloads where a software |
| 23 |
> raid is good enough that spending money on a hardware raid card is |
| 24 |
> pointless. I can not imagine a case where all things being equal that |
| 25 |
> software raid would be measurably faster. |
| 26 |
> |
| 27 |
> In the event that removing your RAID card makes your disk 5x faster |
| 28 |
> I'd also recommend removing the admin who setup the original system as |
| 29 |
> well. :-) |
| 30 |
> |
| 31 |
> kashani |
| 32 |
|
| 33 |
My post did say "Back in the Day" and it was around 1999 that we did |
| 34 |
this however, then I was running unstable raid tools and they have come |
| 35 |
a long way, and I was running 2.2 kernel. |
| 36 |
|
| 37 |
However, the only people I am aware of that say the performance is |
| 38 |
better on hardware raid are hardware raid manufacturers and you... You |
| 39 |
don't work for LSI do you? Most of the linux software folks agree with |
| 40 |
me or take a mildly more conservative tone. |
| 41 |
|
| 42 |
eg: |
| 43 |
|
| 44 |
Redhat Enterprise Linux (circa 2005-2006) |
| 45 |
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/pdf/rhel-isa-en.pdf |
| 46 |
|
| 47 |
Often the excess CPU power available for software RAID parity |
| 48 |
calculations greatly exceeds the processing power present on a RAID |
| 49 |
controller card. Therefore, some software RAID implementations |
| 50 |
actually have the capability for higher performance than hardware RAID |
| 51 |
implementations. |
| 52 |
|
| 53 |
|
| 54 |
|
| 55 |
Mysql: |
| 56 |
|
| 57 |
Hardware Versus Software |
| 58 |
|
| 59 |
Some operating systems can perform software RAID. Rather than buying a |
| 60 |
dedicated RAID controller, the operating system's kernel splits the I/O |
| 61 |
among multiple disks. Many users shy away from using these features |
| 62 |
because they've long been considered slow or buggy. |
| 63 |
|
| 64 |
In reality, software RAID is quite stable and performs rather well. The |
| 65 |
performance differences between hardware and software RAID tend not to |
| 66 |
be significant until they're under quite a bit of load. For smaller and |
| 67 |
medium-sized workloads, there's little discernible difference between |
| 68 |
them. Yes, the server's CPU must do a bit more work when using software |
| 69 |
RAID, but modern CPUs are so fast that the RAID operations consume a |
| 70 |
small fraction of the available CPU time. And, as we stressed earlier, |
| 71 |
the CPU is usually not the bottleneck in a database server anyway. |
| 72 |
|
| 73 |
|
| 74 |
-----BEGIN PGP SIGNATURE----- |
| 75 |
Version: GnuPG v1.4.2 (MingW32) |
| 76 |
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org |
| 77 |
|
| 78 |
iD8DBQFD4Sp7y9wPyZpnL2URAg21AKCjuZUMQhjRq9yx3yswJFGEcM0iTACfWtkB |
| 79 |
g10T1PVfJMB21bWuRCvSLhU= |
| 80 |
=FB7u |
| 81 |
-----END PGP SIGNATURE----- |
| 82 |
-- |
| 83 |
gentoo-server@g.o mailing list |
Archives