From owner-freebsd-bugs@FreeBSD.ORG Mon Dec 19 21:30:14 2011 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id C778E106567D for ; Mon, 19 Dec 2011 21:30:14 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id 5459B8FC19 for ; Mon, 19 Dec 2011 21:30:13 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.5/8.14.5) with ESMTP id pBJLUD3p084465 for ; Mon, 19 Dec 2011 21:30:13 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.5/8.14.5/Submit) id pBJLUDMk084458; Mon, 19 Dec 2011 21:30:13 GMT (envelope-from gnats) Resent-Date: Mon, 19 Dec 2011 21:30:13 GMT Resent-Message-Id: <201112192130.pBJLUDMk084458@freefall.freebsd.org> Resent-From: FreeBSD-gnats-submit@FreeBSD.org (GNATS Filer) Resent-To: freebsd-bugs@FreeBSD.org Resent-Reply-To: FreeBSD-gnats-submit@FreeBSD.org, Garrett Cooper Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1FF21065677 for ; Mon, 19 Dec 2011 21:30:00 +0000 (UTC) (envelope-from nobody@FreeBSD.org) Received: from red.freebsd.org (red.freebsd.org [IPv6:2001:4f8:fff6::22]) by mx1.freebsd.org (Postfix) with ESMTP id D960F8FC13 for ; Mon, 19 Dec 2011 21:30:00 +0000 (UTC) Received: from red.freebsd.org (localhost [127.0.0.1]) by red.freebsd.org (8.14.4/8.14.4) with ESMTP id pBJLU0YP015134 for ; Mon, 19 Dec 2011 21:30:00 GMT (envelope-from nobody@red.freebsd.org) Received: (from nobody@localhost) by red.freebsd.org (8.14.4/8.14.4/Submit) id pBJLU0pU015133; Mon, 19 Dec 2011 21:30:00 GMT (envelope-from nobody) Message-Id: <201112192130.pBJLU0pU015133@red.freebsd.org> Date: Mon, 19 Dec 2011 21:30:00 GMT From: Garrett Cooper To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-3.1 Cc: Subject: kern/163461: vfs.zfs.arc_max/vfs.zfs.arc_meta_limit defaults aren't wise X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 21:30:15 -0000 >Number: 163461 >Category: kern >Synopsis: vfs.zfs.arc_max/vfs.zfs.arc_meta_limit defaults aren't wise >Confidential: no >Severity: critical >Priority: medium >Responsible: freebsd-bugs >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Mon Dec 19 21:30:12 UTC 2011 >Closed-Date: >Last-Modified: >Originator: Garrett Cooper >Release: 10-CURRENT >Organization: n/a >Environment: FreeBSD streetfighter.ixsystems.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227801: Mon Nov 21 14:04:39 PST 2011 root@streetfighter.ixsystems.com:/usr/obj/usr/src/sys/STREETFIGHTER amd64 >Description: There are many instances that I've seen where enabling certain features with ZFS (such as dedup) will go and starve userland of all memory and/or cause the system to dig into swap and die a slow and painful death if not limited, whereas if you limit things it may go slowly, but it will complete in a reasonable period of time. Example: was talking with a user where a zpool import -F took 48+ hours and crashed because it ran out of memory, whereas when I put in more sane limits rerunning the zpool import -F finished within 45 minutes of replaying the ZIL. And this was within both multiuser and singleuser mode! The salient point that I'm bringing up in this ticket is that the defaults need to be low, but smart. In particular, if the defaults for vfs.zfs.arc_max were set to 50% ~ 75% of vm.kmem_size, and vfs.zfs.arc_meta_limit was set to 10% ~ 20% of that, this should suffice for most scenarios, s.t. userland and other kernel processes aren't kicked out of the running for memory. If someone has 1GB of RAM on their box and running with a couple of TB of storage, they should go buy more RAM or switch to UFS -- but 32GB~48GB~192GB machines shouldn't tip over in the field because the code doesn't have sane defaults implemented. >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted: