From owner-freebsd-stable@FreeBSD.ORG Wed Apr 6 10:14:06 2011 Return-Path: Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CFA05106566B for ; Wed, 6 Apr 2011 10:14:06 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 2202D8FC08 for ; Wed, 6 Apr 2011 10:14:05 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (alpha-e.starpoint.kiev.ua [212.40.38.101]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA21945; Wed, 06 Apr 2011 13:14:01 +0300 (EEST) (envelope-from avg@FreeBSD.org) Message-ID: <4D9C3CE8.5090201@FreeBSD.org> Date: Wed, 06 Apr 2011 13:14:00 +0300 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.15) Gecko/20110309 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: Matthias Andree 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> <4D9B6178.7090809@gmx.de> In-Reply-To: <4D9B6178.7090809@gmx.de> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-stable@FreeBSD.org Subject: Re: Kernel memory leak in 8.2-PRERELEASE? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Apr 2011 10:14:06 -0000 on 05/04/2011 21:37 Matthias Andree said the following: > 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. Define "really integrated". > It's not buffer or cache memory, but some True. > separate application memory that can't adapt as quickly to system memory > demands as all other kernel-managed caches and buffers can. Other kernel-managed caches and buffers are not instant either. But I have never compared "speed of adaptions". -- Andriy Gapon