Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Apr 2011 20:37:44 +0200
From:      Matthias Andree <matthias.andree@gmx.de>
To:        freebsd-stable@freebsd.org
Subject:   Re: Kernel memory leak in 8.2-PRERELEASE?
Message-ID:  <4D9B6178.7090809@gmx.de>
In-Reply-To: <4D9B1E50.9020403@FreeBSD.org>
References:  <4D972FF7.6010901@acm.poly.edu>	<20110402153315.GP78089@deviant.kiev.zoral.com.ua>	<4D974393.80606@acm.poly.edu>	<4D9A307F.9070408@acm.poly.edu>	<20110404224334.GA64297@icarus.home.lan>	<4D9A68AA.6040803@acm.poly.edu>	<20110405010148.GA67821@icarus.home.lan> <4D9B1E50.9020403@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Am 05.04.2011 15:51, schrieb Andriy Gapon:

> Boris,
> ARC is an adaptive cache (as its name says), but the adaption doesn't happen
> instantly.  So, when your applications do not use a lot of memory, but there is
> steady filesystem usage, then ZFS ARC is going to gradually grow to consume an
> optimum amount of RAM.  Then, your applications suddenly need a lot more memory,
> they put pressure on VM system, ARC starts to shrink.  But if memory demand grows
> faster than ARC shrinks, you are going to get a memory shortage.  And since you
> don't have any swap to act as a safety net, you are getting out-of-memory situation.
> So no surprises here, no system problems, just a normal foot-shooting :)
> 
> Clamping maximum ARC size, as Jeremy has suggested, should help some.
> Adding some swap would help a lot more.

The problem to me seems that ARC, the way you describe it, isn't really
integrated with the system.  It's not buffer or cache memory, but some
separate application memory that can't adapt as quickly to system memory
demands as all other kernel-managed caches and buffers can.  FWIW, I've
been using it on a 4 GB amd64 computer.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4D9B6178.7090809>