From owner-freebsd-questions@FreeBSD.ORG Mon Feb 16 18:07:22 2015 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 104DEA76 for ; Mon, 16 Feb 2015 18:07:22 +0000 (UTC) Received: from trent.utfs.org (trent.utfs.org [IPv6:2a03:3680:0:3::67]) (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 BE1DAA63 for ; Mon, 16 Feb 2015 18:07:21 +0000 (UTC) Received: by trent.utfs.org (Postfix, from userid 8) id 94A353DCD8; Mon, 16 Feb 2015 19:07:17 +0100 (CET) X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on trent.utfs.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=2.5 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 Received: from trent.utfs.org (localhost [127.0.0.1]) by trent.utfs.org (Postfix) with ESMTP id 5D5C83DB7F; Mon, 16 Feb 2015 19:07:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by trent.utfs.org (Postfix) with ESMTP id 3E9F33DABF; Mon, 16 Feb 2015 19:07:16 +0100 (CET) Date: Mon, 16 Feb 2015 10:07:16 -0800 (PST) From: Christian Kujau To: Fabian Keil Subject: Re: FreeBSD 10.1 crashing under load In-Reply-To: <4e9beab4.5e4e3963@fabiankeil.de> Message-ID: References: <4e9beab4.5e4e3963@fabiankeil.de> User-Agent: Alpine 2.19.4 (DEB 40 2013-11-18) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-AV-Checked: ClamAV using ClamSMTP (127.0.0.1 at Mon Feb 16 19:07:16 2015 +0100 (CET)) Cc: freebsd-questions@freebsd.org X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Feb 2015 18:07:22 -0000 On Mon, 16 Feb 2015 at 11:51, Fabian Keil wrote: > Using a kernel with WITNESS and INVARIANTS sometimes results in > the problem being caught earlier. Hm, I had hoped not to have to recompile the kernel for this, but maybe that's the way to go. I'll look into that, thanks. > IIRC it's not officially supported but you can dump on the device > below the geli layer: > > fk@r500 ~ $swapinfo > Device 1K-blocks Used Avail Capacity > /dev/ada0s1b.eli 2097152 0 2097152 0% > fk@r500 ~ $dumpon -l > ada0s1b (FreeBSD n00b here): indeed, even with dumpdev="AUTO", "dumpon -l" reported /dev/null - I've set this manually to my encrypted swap device now and wait for the next boot. The last involuntary reboot was just a few hours ago, the last known state was: > Mem: 70M Active, 663M Inact, 208M Wired, 4508K Cache, 87M Buf, 32M Free > Swap: 1024M Total, 88M Used, 936M Free, 8% Inuse > Maybe you need to play with vm.overcommit for details see tuning(7). vm.overcommit was set to 0 by default and I would've assumed that this is sufficient: > Setting bit 0 of the vm.overcommit sysctl causes the virtual memory > system to return failure to the process when allocation of memory causes > vm.swap_reserved to exceed vm.swap_total. But instead of one process crashing, the whole machine crashes. I've set it to 2 now and will see if it helps anything. Thanks for your input, Christian. -- BOFH excuse #78: Yes, yes, its called a design limitation