Date: Thu, 01 Oct 2009 22:07:42 PDT From: Dieter <freebsd@sopwith.solgatos.com> To: freebsd-performance@freebsd.org Subject: Re: A specific example of a disk i/o problem Message-ID: <200910020507.FAA13295@sopwith.solgatos.com> In-Reply-To: Your message of "Thu, 01 Oct 2009 09:10:43 EDT." <20091001091043.477f4b9b.wmoran@collaborativefusion.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > >> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200910020507.FAA13295>