Re: Temporary 'lock-up' under heavy write, MegaRAID RAID-5
On Wed, Nov 09, 2005 at 06:42:37PM +0100, Markus Boas wrote:
> Am Mittwoch 09 November 2005 12:25 schrieb Joost Kraaijeveld:
> > On Wed, 2005-11-09 at 11:46 +0100, Dave Ewart wrote:
> > > The above system is incredibly fast under almost all conditions, except
> > > when writing very large files (say, 100s of MB, or even GB). When
> >
> > ....
> >
> > > Any other suggestions or reports of similar experiences?
> >
> > Sorry, no solution, but a me too post. I have similar experience with a
> > 2-way Opteron, 3Ware9500 SATA RAID5 with 5 disks: short updateing
> > transactions with PostgreSQL fly, long updates start fast but after a
> > few seconds everthing locks up, and the update lasts forever.
> >
> Adaptec 3410s had at starting the same troble. Also Raid 5 with 5 disks.
> By updateing the "Bios" of the raid-controller it is better.
> Dual Xeon
This whole thread may be OT for this list, but you guys running 4 way
SMP opterons with three whole drives in a raid 5, throw away those raid
cards and just use the software raid. Then try those tests. Also try
and measure the amount of cpu overhead the software raid incurs. A lot
of people don't use software raid because 'It uses some CPU, doesn't
it?' I tell them, get over the fear and measure. Then decide. On
processors like these, max io performance can be had for about 3-5% of
one of the 4 cpus. Sure beats kicking back and cleaning out your
briefcase every time someone does a write. And when you measure,
measure write performance, and use something like bonnie, which will
tell you the cpu overhead and other useful info. The IO wait data is
also good to know.
Despite what many anecdotally informed people will tell you, software
raid is almost always way faster. Think about it: a modern processor
running at multiple GHz rates with DDR/DDR2 memory, and MMX
instructions versus some tiny little CRC hardare cell on a card running
at 50/100 MHz. It's not even a fair fight. And typically at the limits
of your hardware, the CPU is barely even off idle dealing with it.
The only way to know for sure is to try both and see which one you're
happiest with. Also, many, many factors can interact subtley to affect
raid performance, and often have to be experimented with to find out the
best combination. Stride size, raid controller cache size, disk cache
size, controller capabilities/limitations, file system block size, file
system capabilities/limitations. XFS has typically worked vastly best
for me, then JFS, then ext3, and lastly, reiserfs, which I have had some
*very* bad experiences with.
a
Reply to: