Date: Sun, 05 Sep 2010 09:58:44 -0400 From: jhell <jhell@DataIX.net> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-fs@freebsd.org Subject: Re: zfs very poor performance compared to ufs due to lack of cache? Message-ID: <4C83A214.1080204@DataIX.net> In-Reply-To: <1F64110BFBD5468B8B26879A9D8C94EF@multiplay.co.uk> References: <5DB6E7C798E44D33A05673F4B773405E@multiplay.co.uk><AANLkTi=6bta-Obrh2ejLCHENEbhV5stbMsvfek3Ki4ba@mail.gmail.com><4C825D65.3040004@DataIX.net> <7EA7AD058C0143B2BF2471CC121C1687@multiplay.co.uk> <1F64110BFBD5468B8B26879A9D8C94EF@multiplay.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09/05/2010 09:19, Steven Hartland wrote: >> ----- Original Message ----- From: "jhell" <jhell@DataIX.net> >>> >>> Attached is the needfree patch mentioned in the URL alongside a local >>> system patch to adjust kern.maxusers to no more than 512 on systems that >>> can support it... > > No joy, still drops down to arc_min even with those two patches and > changing > to vm_paging_needed from the post Artem mentioned: > http://lists.freebsd.org/pipermail/freebsd-hackers/2010-August/032731.html > > So I suspect if I hadn't put in a high arc_min as well it would be back > down > at silly low levels. > > top shows:- > > Mem: 26M Active, 1360M Inact, 2434M Wired, 6188K Cache, 418M Buf, 117M Free > Swap: 4096M Total, 15M Used, 4081M Free > > ARC Size: > Current Size: 57.14% 2048.00M (arcsize) > Target Size: (Adaptive) 57.14% 2048.00M (c) > Min Size (Hard Limit): 57.14% 2048.00M (c_min) > Max Size (High Water): ~1:1 3584.00M (c_max) > > So there's still 1.3G of mem sitting inact, don't know what caused that but > its essentially dead memory now it seems. > > I know I could raise arc_min even further but that could be dangerous? > > Any other suggestions? It seems like arc needs to cooperate with the > rest of the OS pagedaemon more? I am not exactly sure what your source is right now but guessing its at least 8.1-RELEASE & hoping its 8.1-STABLE. Line 3656 & 3657 of arc.c ? what are they ? Do they look like the following, 3656: uint64_t available_memory = ptoa((uintmax_t)cnt.v_free_count 3657: + cnt.v_cache_count); Regards, -- jhell,v
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4C83A214.1080204>