> 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.
Ok. That differs significantly from my understanding, though in retrospect I should have realized it given that arc stats contain only references to mru and mfu... I previously was under the impression that the ZFS ARC had an LRU:Ish side to complement the MFU side. MRU+MFU changes things. I will have to look into it in better detail to understand the consequences. Is there a paper that describes the ARC as it is implemented in ZFS (since it clearly diverges from the IBM ARC)? >> 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 For what it's worth I confirmed that the ARC was too small and that there are clearly remaining issues with the interaction between the ARC the rest of the FreeBSD kernel. (I wasn't sure before but I confirmed I Was looking at the right number.) I'll try to monitor more carefully and see if I can figure out when the ARC shrinks and why it doesn't grow back. Informally my observations have always been that things behave great for a while after boot, but degenerate over time. In this case it was sitting at it's minium size, which was 214M. I realize this is far below what is recommended or even designed for, but is it clearly caching *something* and I clearly *could* make it cache urxvt+deps by re-running it several tens of times in rapid succession. > 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? In the urxvt case, I am basing my claim on informal observations. I.e., "hit terminal launch key, wait for disks to rattle, get my terminal". Repeat. Only by repeating it very many times in very rapid succession am I able to coerce it to be cached such that I can immediately get my terminal. And what I mean by that is that it keeps necessitating disk I/O for a long time, even on rapid successive invocations. But once I have repeated it enough times it seems to finally enter the cache. (No dtrace unfortunately. I confess to not having learned dtrace yet, in spite of thinking it's massively cool.) However, I will of course accept that given the minimal ARC size at the time I am moving completely away from the designed-for use-case. And if that is responsible, it is of course my own fault. Given MRU+MFU I'll have to back off with my claims. Under the (incorrect) assumption of LRU+MFU I felt the behavior was unexpected, even with a small cache size. Given MRU+MFU and without knowing further details right now, I accept that the ARC may fundamentally need a bigger cache size in relation to the working set in order to be effective in the way I am using it here. I was basing my expectations on LRU-style behavior. Thanks! -- / Peter Schuller _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
