On Apr 5, 2010, at 2:23 PM, Peter Schuller wrote:
> That's a very general statement. I am talking about specifics here.
> For example, you can have mountains of evidence that shows that a
> plain LRU is "optimal" (under some conditions). That doesn't change
> the fact that if I want to avoid a sequential scan of a huge data set
> to completely evict everything in the cache, I cannot use a plain LRU.
In simple terms, the ARC is divided into a MRU and MFU side.
target size (c) = target MRU size (p) + target MFU size (c-p)
On Solaris, to get from the MRU to the MFU side, the block must be
read at least once in 62.5 milliseconds. For pure read-once workloads,
the data won't to the MFU side and the ARC will behave exactly like an
(adaptable) MRU cache.
> In this case I'm looking for the reverse; i.e., increasing the
> importance of 'recenticity' because my workload is such that it would
> be more optimal than the behavior I am observing. Benchmarks are
> irrelevant except insofar as they show that my problem is not with the
> caching policy, since I am trying to address an empirically observed
> behavior.
>
> I *will* try to look at how the ARC sizes itself, as I'm unclear on
> several things in the way memory is being reported by FreeBSD, but as
> far as I can tell these are different issues. Sure, a bigger ARC might
> hide the behavior I happen to see; but I want the cache to behave in a
> way where I do not need gigabytes of extra ARC size to "lure" it into
> caching the data necessary for 'urxvt' without having to start it 50
> times in a row to accumulate statistics.
I'm not convinced you have attributed the observation to the ARC
behaviour. Do you have dtrace (or other) data to explain what process
is causing the physical I/Os?
-- richard
ZFS storage and performance consulting at http://www.RichardElling.com
ZFS training on deduplication, NexentaStor, and NAS performance
Las Vegas, April 29-30, 2010 http://nexenta-vegas.eventbrite.com
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
