[EMAIL PROTECTED] wrote on 02/26/2007 11:36:18 AM:
> Jeff Davis wrote:
> >> Given your question are you about to come back with a
> >> case where you are not
> >> seeing this?
> >
> > Actually, the case where I saw the bad behavior was in Linux using
> the CFQ I/O scheduler. When reading the same file sequentially,
> adding processes drastically reduced total disk throughput (single
> disk machine). Using the Linux anticipatory scheduler worked just
> fine: no additional I/O costs for more processes.
> >
> > That got me worried about the project I'm working on, and I wanted
> to understand ZFS's caching behavior better to prove to myself that
> the problem wouldn't happen under ZFS. Clearly the block will be in
> cache on the second read, but what I'd like to know is if ZFS will
> ask the disk to do a long, efficient sequential read of the disk, or
> whether it will somehow not recognize that the read is sequential
> because the requests are coming from different processes?
> >
This gets complicated quickly, here is how I understand it to be:
"if you have N processes reading the same file sequentially (where file
size is much greater than physical memory)."
to me inherently means that the cache will not have the file completely
cached for multiple processes. If you have N processes in different read
stages (first block, middle block, last block) on a file described above,
there will be a sliding/fragmented window of cached/prefetched data (with
complex dynamics because fo the IO scheduler and ARC). When you have N
procs that window the ARC cache you will not get (near) 100% cache hits,
and depending on how large the file is compared to the available ARC and
other fs loads you may get very poor cache hits. If all of the procs start
reading the file at the same relative time and read at about the same rate
your cache hits will be higher as this allows the ARC/Prefetch/IO Scheduler
to have the best chance of covering the reads.
The closer the filesize is to available ARC memory, the closer the
procs are grouped together on reads of the same blocks and fewer groupings
you have of those proc read groups the better your cache rate will be. In
any case do not expect 1:IO or N:IO. it will be somewhere in the middle
depending on the specifics of workload.
-Wade
_______________________________________________
zfs-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
