On Wed, 15 Jul 2009, Ross wrote:

Yes, that makes sense. For the first run, the pool has only just been mounted, so the ARC will be empty, with plenty of space for prefetching.
I don't think that this hypothesis is quite correct.  If you use 
'zpool iostat' to monitor the read rate while reading a large 
collection of files with total size far larger than the ARC, you will 
see that there is no fall-off in read performance once the ARC becomes 
full.  The performance problem occurs when there is still metadata 
cached for a file but the file data has since been expunged from the 
cache.  The implication here is that zfs speculates that the file data 
will be in the cache if the metadata is cached, and this results in a 
cache miss as well as disabling the file read-ahead algorithm.  You 
would not want to do read-ahead on data that you already have in a 
cache.
Recent OpenSolaris seems to take a 2X performance hit rather than the 
4X hit that Solaris 10 takes.  This may be due to improvement of 
existing algorithm function performance (optimizations) rather than a 
related design improvement.
I wonder if there is any tuning that can be done to counteract this? Is there any way to tell ZFS to bias towards prefetching rather than preserving data in the ARC? That may provide better performance for scripts like this, or for random access workloads.
Recent zfs development focus has been on how to keep prefetch from 
damaging applications like database where prefetch causes more data to 
be read than is needed.  Since OpenSolaris now apparently includes an 
option setting which blocks file data caching and prefetch, this seems 
to open the door for use of more aggressive prefetch in the normal 
mode.
In summary, I agree with Richard Elling's hypothesis (which is the 
same as my own).
Bob
--
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to