Subject: Re: 3ware RAID controller slow?
To: Jukka Marin <>
From: Adam Hamsik <>
List: netbsd-users
Date: 10/28/2007 14:03:58
Hash: SHA1

On Oct,Sunday 28 2007, at 1:59 PM, Jukka Marin wrote:

> On Sat, Oct 27, 2007 at 03:42:03PM -0500, Johan A. van Zanten wrote:
>> The larger transfer units (bs=10m) are dramtically improving your
>> performance with dd.
>> I think the default block size (AKA "blocking factor") for tar is 20
>> 512-byte blocks, so that's 10 KB transfer unit.  That's less than  
>> 1/1000th
>> the unit in the dd command you are using.
> There's something odd going on.  It's probably caused by softdep or  
> something.
> This system had 4 GB of RAM, so the pkgsrc tree fits in RAM.   
> Sometimes,
> extracting the tarball takes only 13 secods or so (obviously, most  
> of the
> data is not written on disk in that time).  Sometimes, the same  
> operation
> takes almost 6 minutes.  Hmm, maybe it depends on whether syncer  
> kicks in
> during the untar operation or not.
> When the RAID5 performance drops, the transfer count (per second)  
> drops
> from ~10000 to 200 or below (to about 300...400 kB/s).  When this  
> happens,
> the RAID controller appears to be busy as the single disk behind the
> controller also becomes real slow (loading a shell command takes  
> several
> seconds).
>>  It'd be interesting to see how "dd if=/dev/zero of=foo bs=10k  
>> count=1000"
>> performs.
> It makes no difference.  Both 10k and 10m block sizes give write  
> speed of
> 173...175 MB/s sustained (average over 10 gigabytes of data).
> I want to create a server which can stream video and audio and is  
> not killed
> by a few gcc or cvs processes running.  At the moment, I'm not  
> confident that
> I can accomplish this.  It seems a simple untar can bring all other  
> disk I/O
> to halt.  I hope someone can see whan I'm doing wrong here?

can you increase kern.maxvnodes to bigger value ?

>   -jm



Version: GnuPG v1.4.7 (Darwin)