From owner-freebsd-fs@freebsd.org Wed Jul 15 19:43:32 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3BCD49A2915 for ; Wed, 15 Jul 2015 19:43:32 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1032A1A2A for ; Wed, 15 Jul 2015 19:43:31 +0000 (UTC) (envelope-from feld@FreeBSD.org) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0DC12208E7 for ; Wed, 15 Jul 2015 15:43:31 -0400 (EDT) Received: from web3 ([10.202.2.213]) by compute5.internal (MEProxy); Wed, 15 Jul 2015 15:43:31 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=qFLf8LH1a9u4yj0 qCJWvQbW4sBM=; b=rquQnQ4BGKeYlALYp8WIkyl9Su5n+U8tUW+KaUud6xiUsOe wI1tiUeAEuH3Br+C33ivBWZIIOjkbQzskA7zPRaePfaWIj8VEQsRJJu/LamDPwPw jtYy5NroBRbolAueXMnjuP1Hlqvkb0dwPZjDjJv4LoMtqjnFnqvkD9G32PkI= Received: by web3.nyi.internal (Postfix, from userid 99) id DF7F510DF90; Wed, 15 Jul 2015 15:43:30 -0400 (EDT) Message-Id: <1436989410.1427298.324703241.421E814B@webmail.messagingengine.com> X-Sasl-Enc: fccPh+gYR3qspyxbwjAFaBU4kW6O3je3VtA4a1iB1j+l 1436989410 From: Mark Felder To: Sean Chittenden , Adrian Gschwend Cc: FreeBSD Filesystems MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-63a5d8c6 Subject: Re: FreeBSD 10.1 Memory Exhaustion Date: Wed, 15 Jul 2015 14:43:30 -0500 In-Reply-To: References: <55A3A800.5060904@denninger.net> <55A4D5B7.2030603@freebsd.org> <55A4E5AB.8060909@netlabs.org> X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 19:43:32 -0000 On Tue, Jul 14, 2015, at 10:10, Sean Chittenden wrote: > I think the reason this is not seen more often is because people > frequently > throw limits on the arc in /boot/loader.conf: > > vfs.zfs.arc_min="18G" > vfs.zfs.arc_max="149G" > > ZFS ARC *should* not require those settings, but does currently for mixed > workloads (i.e. databases) in order to be "stable". By setting fixed > sizes > on the ARC, UMA and ARC are much more cooperative in that they have their > own memory regions to manage so this behavior is not seen as often. > > To be clear, however, it should not be necessary to set parameters like > these in /boot/loader.conf in order to obtain consistent operational > behavior. I'd be curious to know if someone running 10.2 BETA without > patches is able to trigger this behavior or not. There was work done > that > reported helped with this between 10.1 and now. To what extent it > helped, > however, I don't have any advice yet. > I was about to email "I have 12TB at home and 4GB of RAM with a very erratic workload and never run into any issues" and then I looked at /boot/loader.conf and saw vfs.zfs.arc_max="2G" Now I'm too scared to turn it off... :-)