From owner-freebsd-stable@FreeBSD.ORG Tue Apr 5 18:37:50 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 C9B611065672 for ; Tue, 5 Apr 2011 18:37:50 +0000 (UTC) (envelope-from matthias.andree@gmx.de) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by mx1.freebsd.org (Postfix) with SMTP id EFAB48FC0C for ; Tue, 5 Apr 2011 18:37:49 +0000 (UTC) Received: (qmail invoked by alias); 05 Apr 2011 18:37:47 -0000 Received: from f055202252.adsl.alicedsl.de (EHLO apollo.emma.line.org) [78.55.202.252] by mail.gmx.net (mp062) with SMTP; 05 Apr 2011 20:37:47 +0200 X-Authenticated: #428038 X-Provags-ID: V01U2FsdGVkX1+FRuwv1meFuhuS+ANrZu+ouF/KxB153IJwz+leUZ oDkY7LptHTlSeP Received: from [IPv6:::1] (unknown [IPv6:::1]) by apollo.emma.line.org (Postfix) with ESMTP id A6DF725AD7B for ; Tue, 5 Apr 2011 20:37:44 +0200 (CEST) Message-ID: <4D9B6178.7090809@gmx.de> Date: Tue, 05 Apr 2011 20:37:44 +0200 From: Matthias Andree User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.14) Gecko/20110223 Mnenhy/0.8.3 Thunderbird/3.1.8 MIME-Version: 1.0 To: freebsd-stable@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> In-Reply-To: <4D9B1E50.9020403@FreeBSD.org> X-Enigmail-Version: 1.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 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: Tue, 05 Apr 2011 18:37:50 -0000 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.