From owner-freebsd-performance@FreeBSD.ORG Fri Oct 2 05:11:54 2009 Return-Path: Delivered-To: freebsd-performance@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D8030106575C for ; Fri, 2 Oct 2009 05:11:54 +0000 (UTC) (envelope-from freebsd@sopwith.solgatos.com) Received: from sopwith.solgatos.com (pool-173-50-131-36.ptldor.fios.verizon.net [173.50.131.36]) by mx1.freebsd.org (Postfix) with ESMTP id DB28D8FC22 for ; Fri, 2 Oct 2009 05:11:53 +0000 (UTC) Received: by sopwith.solgatos.com (Postfix, from userid 66) id 27B08B64F; Thu, 1 Oct 2009 22:09:57 -0700 (PDT) Received: from localhost by sopwith.solgatos.com (8.8.8/6.24) id FAA13295; Fri, 2 Oct 2009 05:07:42 GMT Message-Id: <200910020507.FAA13295@sopwith.solgatos.com> To: freebsd-performance@freebsd.org In-reply-to: Your message of "Thu, 01 Oct 2009 09:10:43 EDT." <20091001091043.477f4b9b.wmoran@collaborativefusion.com> Date: Thu, 01 Oct 2009 22:07:42 PDT From: Dieter Subject: Re: A specific example of a disk i/o problem X-BeenThere: freebsd-performance@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Performance/tuning List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Oct 2009 05:11:54 -0000 > > > >> > My question is why is FreeBSD's disk i/o performance so bad? > > > > > > Here is a specific demo of one disk i/o problem I'm seeing. Should be > > > > easy to reproduce? > > > > > > > > http://lists.freebsd.org/pipermail/freebsd-performance/2008-July/003533.html > > FYI, I thought I'd play around with this some in an attempt to add some > useful information to the investigation. > > I can not reproduce the problem at all. I created a 9G file, did the cat > as described in the above URL, and the man request completed in roughly > the same time it did without the cat running. How large is main memory on this machine? e.g. is 9 GB large enough to flush everything else out of the disk cache before running the man command again? I haven't studied the new unified memory thing, but if we assume worst case, reading at 50 M/s would take 40 seconds to flush 2 GiB. BTW there is nothing magic about a 9 GB file, just that it is large enough to flush the 2 GiB of main memory on my machine and takes long enough to read to notice a difference in how long it takes to run man. Updated demo, just to make sure: # big_file is larger than main memory, on same disk as man (/usr) time man de # get baseline time for man command without competing i/o cat big_file > /dev/null # flush man command and data from memory cat big_file > /dev/null & # generate i/o, attempt to use up bottleneck time man de # see how much longer man takes with competing i/o