Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Oct 2004 12:32:23 -0300
From:      =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= <jonny@jonny.eng.br>
To:        Mike Horwath <drechsau@geeks.org>
Cc:        freebsd-performance@freebsd.org
Subject:   Re: Disk I/O Performance
Message-ID:  <41768507.3070304@jonny.eng.br>
In-Reply-To: <20041019205225.GB39270@octanews.net>
References:  <20041019193501.GC78974@cybernetik.net> <41756EBF.3010008@jonny.eng.br> <20041019205225.GB39270@octanews.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Mike Horwath wrote:
> On Tue, Oct 19, 2004 at 04:45:03PM -0300, João_Carlos_Mendes_Luís wrote:
> 
>>    I'd say that you have to check which CCD chunk size is best for 
>>your needs.  The manual for vinum recommends avoiding chunk sized to a 
>>power of two, which is probably the first big mistake of everybody.
>>
>>    Try mounting with option noatime, if you haven't already.  And use 
>>the largest block size possible when formatting.  Last time I read about 
>>there was a limit of 16384, but I would expect better performance for 
>>large file with 64k blocks (and 8k frags).
>>
>>    If you don't have a need for safety on the files, you could try 
>>mount async and measure if it suits better you need for performance than 
>>softupdates.  Sometimes softupdates is faster, and it is always safer.
> 
> 
> All good ideas except the issue is bandwidth performance across the
> disks.
> 
> I am seeing the same thing (and Kristofer and I have been working
> together, kinda, on this).  It is as if I/O is being preferred for
> writing vs reading, very weird.
> 
> His 5 disk stripe (well, it used to be five when I managed the
> machine) should not have issues, but this recently begun happening
> both on his systems and some of mine.

     Did you make a software upgrade recently?  This could point to some 
changes in the device driver.  If this is the case, them a downgrade 
could help.

     Indeed, I would expect that, if both happened at the same time, 
write should have more preference than read.  This would release buffers 
faster and keep sensible data in RAM for the minimum time possible.  Of 
course, only after softupdates have released the data for writing, at 
the block device level.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?41768507.3070304>