From owner-freebsd-performance@FreeBSD.ORG Wed Oct 20 15:32:30 2004 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5DF416A4CE for ; Wed, 20 Oct 2004 15:32:30 +0000 (GMT) Received: from minerva.int.gov.br (nat.int.gov.br [200.20.196.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F8F643D1F for ; Wed, 20 Oct 2004 15:32:30 +0000 (GMT) (envelope-from jonny@jonny.eng.br) Received: from dinf-02.int.gov.br (dinf-02 [10.0.8.17]) by minerva.int.gov.br (Postfix) with ESMTP id CA618BE5B1; Wed, 20 Oct 2004 12:32:27 -0300 (BRT) Received: from 127.0.0.1 (AVG SMTP 7.0.280 [264.12.0]); Wed, 20 Oct 2004 12:32:23 -0300 Message-ID: <41768507.3070304@jonny.eng.br> Date: Wed, 20 Oct 2004 12:32:23 -0300 From: =?ISO-8859-1?Q?Jo=E3o_Carlos_Mendes_Lu=EDs?= User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mike Horwath References: <20041019193501.GC78974@cybernetik.net> <41756EBF.3010008@jonny.eng.br> <20041019205225.GB39270@octanews.net> In-Reply-To: <20041019205225.GB39270@octanews.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit cc: Kristofer Pettijohn cc: freebsd-performance@freebsd.org Subject: Re: Disk I/O Performance X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Oct 2004 15:32:30 -0000 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.