A specific example of a disk i/o problem

[Dieter]

> > > >> > 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