So it looks like this data does not include ::kmastat info from *after*
you reset arc_reduce_dnlc_percent. Can I get that?
What I suspect is happening:
1 with your large ncsize, you eventually ran the machine out
of memory because (currently) the arc is not accounting for
the space consumed by "auxiliary" caches (dnode_t, etc.).
2 the arc could not reduce at this point since almost all of
its memory was tied up by the dnlc refs.
3 when you eventually allowed the arc to reduce the dnlc size,
it managed to free up some space, but much of this did not
"appear" because it was tied up in slabs in the auxiliary
caches (fragmentation).
We are working on a fix for number 1 above.
You should *not* be setting arc_reduce_dnlc_percent to zero, even if
you want a large number of dnlc entries. You are tying the arc hands
here, so it has no ability to reduce its size.
Number 3 is the most difficult issue. We are looking into that at the
moment as well.
-Mark
Tomas Ögren wrote:
On 05 January, 2007 - Mark Maybee sent me these 0,8K bytes:
Thomas,
This could be fragmentation in the meta-data caches. Could you
print out the results of ::kmastat?
http://www.acc.umu.se/~stric/tmp/zfs-dumps.tar.bz2
memstat, kmastat and dnlc_nentries from 10 minutes after boot up until
the "near death experience"..
I've got vmcore as well if needed..
/Tomas
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
