Subject: Re: 3ware RAID controller slow?
To: Jukka Marin <firstname.lastname@example.org>
From: Adam Hamsik <email@example.com>
Date: 10/28/2007 14:03:58
-----BEGIN PGP SIGNED MESSAGE-----
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
>> the unit in the dd command you are using.
> There's something odd going on. It's probably caused by softdep or
> This system had 4 GB of RAM, so the pkgsrc tree fits in RAM.
> 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
> 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)
> from ~10000 to 200 or below (to about 300...400 kB/s). When this
> the RAID controller appears to be busy as the single disk behind the
> controller also becomes real slow (loading a shell command takes
>> It'd be interesting to see how "dd if=/dev/zero of=foo bs=10k
> 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 ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
-----END PGP SIGNATURE-----