From owner-freebsd-fs@freebsd.org Tue Jul 14 16:11:11 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 94A119A17C5 for ; Tue, 14 Jul 2015 16:11:11 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from smtp-outbound.userve.net (smtp-outbound.userve.net [217.196.1.22]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.userve.net", Issuer "Go Daddy Secure Certificate Authority - G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E4B53EF5 for ; Tue, 14 Jul 2015 16:11:10 +0000 (UTC) (envelope-from matt.churchyard@userve.net) Received: from owa.usd-group.com (owa.usd-group.com [217.196.1.2]) by smtp-outbound.userve.net (8.14.7/8.14.7) with ESMTP id t6EFn5qb076141 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2015 16:49:05 +0100 (BST) (envelope-from matt.churchyard@userve.net) Received: from SERVER.ad.usd-group.com (192.168.0.1) by SERVER.ad.usd-group.com (192.168.0.1) with Microsoft SMTP Server (TLS) id 15.0.847.32; Tue, 14 Jul 2015 16:49:05 +0100 Received: from SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9]) by SERVER.ad.usd-group.com ([fe80::b19d:892a:6fc7:1c9%12]) with mapi id 15.00.0847.030; Tue, 14 Jul 2015 16:49:05 +0100 From: Matt Churchyard To: Sean Chittenden , Adrian Gschwend CC: FreeBSD Filesystems Subject: RE: FreeBSD 10.1 Memory Exhaustion Thread-Topic: FreeBSD 10.1 Memory Exhaustion Thread-Index: AQHQvWHT+mqLQQIA90upWPLaPGA5Dp3ZOw8AgAFnrICAABMFgIAATSmAgAARnMA= Date: Tue, 14 Jul 2015 15:49:04 +0000 Message-ID: References: <55A3A800.5060904@denninger.net> <55A4D5B7.2030603@freebsd.org> <55A4E5AB.8060909@netlabs.org> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.10] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 14 Jul 2015 16:11:11 -0000 Yes, I'm one of those and I suspect it's very common. I generally just use official FreeBSD releases and let the devs decide what= patches are/aren't applied. However, I limit max ARC on all my ZFS systems to leave a few GB or so (my = latest system has limit of 28G with 32GB total) Last time I didn't limit ARC was a new system about a year ago and it panic= ed due to memory after a few days I don't bother letting it near all my RAM anymore. For me (and probably many other ZFS users that want their machines to stay = up more than a few days) it's much easier to do this, than to run manually = patched kernels that *might* fix it, but *might* also cause other problems.= Also allows me control over how much ZFS has, and how much I leave for my = other applications. Would be nice if it 'just worked', but I'll be very reluctant to take the l= imits off. -Matt -----Original Message----- From: owner-freebsd-fs@freebsd.org [mailto:owner-freebsd-fs@freebsd.org] On= Behalf Of Sean Chittenden Sent: 14 July 2015 16:10 To: Adrian Gschwend Cc: FreeBSD Filesystems Subject: Re: FreeBSD 10.1 Memory Exhaustion 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=3D"18G" vfs.zfs.arc_max=3D"149G" ZFS ARC *should* not require those settings, but does currently for mixed w= orkloads (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 o= wn 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 the= se 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 ab= le to trigger this behavior or not. There was work done that reported help= ed with this between 10.1 and now. To what extent it helped, however, I do= n't have any advice yet. -sc On Tue, Jul 14, 2015 at 3:34 AM, Adrian Gschwend wrote= : > On 14.07.15 11:26, Matthew Seaman wrote: > > > > On 07/13/15 12:58, Karl Denninger wrote: > >> Put this on your box and see if the problem goes away.... :-) > > [...] > > > I know that you, Karl, and a number of others have been advocating=20 > > to get this patch set committed. Having now personally run into the=20 > > sort of problems that this addresses I can say that I would very=20 > > much like to see this go in. Conditional of course on this actually=20 > > solving the problems I and others have been experiencing without=20 > > introducing significant regressions elsewhere. It's only had a day's=20 > > testing from me so far, but it's looking good. If it survives a=20 > > week without the system locking up, I'll be convinced. > > I was the one which posted the message last year which triggered Karl=20 > to analyze it as he saw similar issues: > > https://lists.freebsd.org/pipermail/freebsd-fs/2014-March/019043.html > > https://lists.freebsd.org/pipermail/freebsd-fs/2014-March/019057.html > > Since then I run on Karls patch and never had any issue anymore. Not=20 > that my boxes were basically unusable without the patch. > > So I'm basically hoping since then that the patch will be committed soon. > > > * The memory exhaustion effect or equivalent memory pressures can be > > triggered at will > > * The test doesn't require unfeasibly large resources to run > > * The behaviour provides a good model for real-world deployments > > > > Maybe these tests would be too large-scale to run every day in=20 > > Jenkins, but having them available as part of, say, the release=20 > > process, seems like a no-brainer to me. > > I wouldn't consider my setup as "unfeasibly large resources", in fact=20 > I triggered it with a bunch of jails running on a machine and=20 > providing various Internet-services for a small Open Source community.=20 > I was always surprised that not more people ran into this issue as I=20 > had it since 8.x. > > regards > > Adrian > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" > -- Sean Chittenden _______________________________________________ freebsd-fs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-fs To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org"