Robert Milkowski wrote:
::dnlc!wc
1048545 3145811 76522461
Well, that explains half your problem... and maybe all of it:
We have a thread that *should* be trying to free up these entries
in the DNLC, however it appears to be blocked:
stack pointer for thread 2a10014fcc0: 2a10014edd1
[ 000002a10014edd1 turnstile_block+0x5e8() ]
000002a10014ee81 mutex_vector_enter+0x424(181bad0, fffe9bac45d5c95c,
6000e685bc8, 30001119340, 30001119340, 0)
000002a10014ef31 zfs_zinactive+0x24(300a9196f00, 6000e685bc8,
6000e685a58,
6000e685980, 300a9196f28, 300c11d7b40)
000002a10014efe1 zfs_inactive+0x168(6000e6859d8, 60001001ee8,
2a10014f948, 2,
0, 300a9196f00)
000002a10014f091 fop_inactive+0x50(300c11d7b40, 60001001ee8, 2000,
60004511f00 , 1, 7b763864)
000002a10014f151 do_dnlc_reduce_cache+0x210(0, 1853da0, 1863c70,
6000175c868,
18ab838, 60cbd)
000002a10014f201 taskq_d_thread+0x88(60003f9f4a0, 300002878c0,
6000100b520, 0
, 1636a70535248, 60003f9f4d0)
000002a10014f2d1 thread_start+4(60003f9f4a0, 0, 60000057b48,
ffbffc6f00000000
, 4558505f53544445, 5252000000000000)
We are trying to obtain a mutex that is currently held by another
thread trying to get memory.
I suspect that the rest of the active vnodes are probably being held
by the arc, as a side-effect of the fact that its holding onto the
associated dnodes (and its holding onto these dnodes because they are
in the same block as some still-dnlc-referenced vnode/dnode). Note
that almost all of the arc memory is tied up in the MRU cache:
> ARC_mru::print
{
list = 0x80
lsize = 0x200
size = 0x8a030400
hits = 0x16dcadb
mtx = {
_opaque = [ 0 ]
}
}
Almost none of this is freeable, so the arc cannot shrink in size.
-Mark
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
