A specific example of a disk i/o problem
freebsd at sopwith.solgatos.com
Fri Oct 2 05:11:54 UTC 2009
> > > >> > 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
More information about the freebsd-performance