Hi,
This same dump has now shown up as a P1 pts-kernel esc of which I am the
lucky owner.
I noticed that arc.size is far smaller than the sum of all zio... caches.
This of course might be caused by :
6456888 zpool scrubbing leads to memory exhaustion and system hang
Except that there is no resilvering going on. There is actually no
mirroring/raidz configured.
I have not created a new bug for this yet.
One of the shares has ~40M files, and this might explain the huge amount
of accessed znodes.
As for the huge number of cached znodes, dnlc size is not the only
issue, as we have 1M dncl entries for 2.3M znodes (dnodes and vnodes) :
there should be a tunable for max number of cached znodes/dnodes as
there is in other file systems. Default should not go beyond ncsize.
Created 6468211
node/dnode caches should not be allowed to grow without bounds.
As for arc.c_max, it should be settable via /etc/system.
Created 6468214
arc.c_max should be tunable.
And last but not least, since the dump has the same size as system ram,
zio... caches are dumped as well. On big systems, this will lead to dump
failures, hampering the resolution of non zfs issues as well as zfs
ones. zio... caches should be skipped by the dump process.
Philippe
Mark Maybee wrote:
Robert Milkowski wrote:
On Wed, 6 Sep 2006, Mark Maybee wrote:
Robert Milkowski wrote:
::dnlc!wc
1048545 3145811 76522461
Well, that explains half your problem... and maybe all of it:
After I reduced vdev prefetch from 64K to 8K for last few hours
system is working properly without workaround and free memory stays
at about 1GB.
Reducing vdev prefetch to 8K alse reduced read thruoutput 10x.
I belive this is somehow related - maybe vdev cache was so aggressive
(I got 40-100MB/s of reads) and consuming memory so fast that thread
which is supposed to regain some memory couldn't keep up?
I suppose, although the data volume doesn't seem that high... maybe you
are just operating at the hairy edge here. Anyway, I have filed a bug
to track this issue:
6467963 do_dnlc_reduce_cache() can be blocked by ZFS_OBJ_HOLD_ENTER()
-Mark
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
--
_____________________________________________________________________
Philippe Magerus [EMAIL PROTECTED]
PTS Emea Kernel (+352) 49.11.33.73
http://luxweb.luxembourg/~philippm
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
