>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 r...@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: _______________________________________________ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
