From nobody@FreeBSD.org  Mon Dec 19 21:30:00 2011
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id F1FF21065677
	for <freebsd-gnats-submit@FreeBSD.org>; 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 <freebsd-gnats-submit@FreeBSD.org>; 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 <freebsd-gnats-submit@FreeBSD.org>; 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 <yaneurabeya@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: vfs.zfs.arc_max/vfs.zfs.arc_meta_limit defaults aren't wise
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         163461
>Category:       kern
>Synopsis:       [vfs] 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:  Sun Feb 03 22:29:51 UTC 2013
>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:
