search for: dnlc_reduce_cache

Hello All, Awhile back (Feb ''07) when we noticed ZFS was hogging all the memory on the system, y''all were kind enough to help us use the arc_max tunable to attempt to limit that usage to a hard value. Unfortunately, at the time a sticky problem was that the hard limit did not include DNLC entries generated by ZFS. I''ve been watching the list since then and trying to

...mmon/fs/zfs/arc.c usr/src/uts/common/fs/zfs/arc.c --- ../opensolaris-20060313/usr/src/uts/common/fs/zfs/arc.c 2006-03-14 21:05:00.000000000 +0100 +++ usr/src/uts/common/fs/zfs/arc.c 2006-03-18 18:06:02.959972174 +0100 @@ -1212,6 +1212,11 @@ * up too much memory. */ dnlc_reduce_cache((void *)(uintptr_t)arc_reduce_dnlc_percent); + + /* + * Reclaim unused memory from all kmem caches. + */ + kmem_reap(); #endif /* This message posted from opensolaris.org

Hello. We''re currently using a Sun Blade1000 (2x750MHz, 1G ram, 2x160MB/s mpt scsi buses, skge GigE network) as a NFS backend with ZFS for distribution of free software like Debian (cdimage.debian.org, ftp.se.debian.org) and have run into some performance issues. We are running SX snv_48 and have run with a raidz2 with 7x300G for a while now, just added another 7x300G raidz2 today but

Has anyone else noticed a significant zfs performance deterioration when running recent opensolaris bits? My 32-bit / 768 MB Toshiba Tecra S1 notebook was able to do a full opensolaris release build in ~ 4 hours 45 minutes (gcc shadow compilation disabled; using an lzjb compressed zpool / zfs on a single notebook hdd p-ata drive). After upgrading to 2007-05-25 opensolaris release bits