Subject: Improving software RAID-5 write performance?
To: None <netbsd-users@netbsd.org>
From: Johnny Lam <jlam@jgrind.org>
List: netbsd-users
Date: 12/11/2001 07:09:14
Hi,
I was wondering if there are hints anyone can provide on how to
increase the write performance of RAID-5 devices configured with RAIDframe
on NetBSD-1.5.3_ALPHA. I've fiddled with different block sizes and
cylinder counts when newfs'ing, but write performance always roughly an
order of magnitude slower than read performance. My setup is 3 SCSI Ultra
160 drives on one AIC-7899 controller, and there are 2GB and 15BG partitions
on each drive devoted to two separate RAID-5 partitions. The tests I'm
running are currently just on the RAID-5 composed from the 2GB partitions.
Typical results from bonnie++ are:
Version 1.01 ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
flatland 300M 4855 10 4833 2 3398 5 30301 94 37835 18 163.3 2
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 39 6 +++++ +++ 162 3 39 6 952 99 75 4
(using 32 sectors per stripe unit, 8K block sizes, and 16 cylinders per group).
I know it's not a fair comparison, but for the sake of having something
concrete to compare to, the results for a hardware RAID-5 device on a slow
alpha are:
Version 1.02a ------Sequential Output------ --Sequential Input- --Random-
-Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
hardware-raid5 300M 16281 51 15839 9 7809 7 16598 64 16804 10 188.7 1
------Sequential Create------ --------Random Create--------
-Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
16 80 8 27481 100 159 4 82 8 1248 99 175 11
Any hints on improving performance will be much appreciated.
Thanks,
-- Johnny Lam <jlam@jgrind.org>