NetBSD Problem Report #47018

From campbell@mumble.net  Sun Sep 30 00:03:09 2012
Return-Path: <campbell@mumble.net>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
	by www.NetBSD.org (Postfix) with ESMTP id 1468363D798
	for <gnats-bugs@gnats.NetBSD.org>; Sun, 30 Sep 2012 00:03:09 +0000 (UTC)
Message-Id: <20120930000246.E7A3C604B3@jupiter.mumble.net>
Date: Sun, 30 Sep 2012 00:02:46 +0000 (UTC)
From: Taylor R Campbell <campbell+netbsd@mumble.net>
Reply-To: Taylor R Campbell <campbell+netbsd@mumble.net>
To: gnats-bugs@gnats.NetBSD.org
Subject: various rlimits are small for modern machines
X-Send-Pr-Version: 3.95

>Number:         47018
>Notify-List:    gson@gson.org
>Category:       misc
>Synopsis:       various rlimits are small for modern machines
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Sep 30 00:05:00 +0000 2012
>Last-Modified:  Sat Jan 17 14:24:46 +0000 2015
>Originator:     Taylor R Campbell <campbell+netbsd@mumble.net>
>Release:        NetBSD 6.99.4
>Organization:
>Environment:
Architecture: i386
Machine: i386
>Description:

	Various rlimits are set to very small values by default, such
	as maxproc=128, descriptors=128, and datasize=256M; or at
	least, I see these defaults on my 2-core i386 with 2 GB RAM and
	my 12-core amd64 with 32 GB RAM -- I'm not sure exactly where
	they're set.  It would be nice if these scaled with the
	available RAM or something.

>How-To-Repeat:

	Try `build.sh -j12 distribution' on a machine with 12 cores and
	32 GB RAM.  Watch it fail on vfork when enough subprocesses
	have been started.

>Fix:

	Yes, please!

>Release-Note:

>Audit-Trail:
From: Matthew Mondor <mm_lists@pulsar-zone.net>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: misc/47018: various rlimits are small for modern machines
Date: Fri, 20 Jun 2014 03:49:49 -0400

 On Sun, 30 Sep 2012 00:05:00 +0000 (UTC)
 Taylor R Campbell <campbell+netbsd@mumble.net> wrote:

 > 	Various rlimits are set to very small values by default, such
 > 	as maxproc=128, descriptors=128, and datasize=256M; or at
 > 	least, I see these defaults on my 2-core i386 with 2 GB RAM and
 > 	my 12-core amd64 with 32 GB RAM -- I'm not sure exactly where
 > 	they're set.  It would be nice if these scaled with the
 > 	available RAM or something.

 I also noticed how high I must increase the file descriptor limit per
 process to use a modern Firefox.  When using ECL, which by default
 configures the boehm-gc heap to use 1GB, the default settings are
 also too low.  Although I've not used linux-compat in a while, I
 remember needing to raise some limits for Flash and Java to work back
 when I did.  So I agree that the defaults should be higher, at least on
 amd64.

 I'm not against heuristics to setup defaults depending on RAM at boot,
 however they could be hard to get right depending on machine usage.

 As for the current ways to configure them, there are login classes
 (/etc/login.conf, login.conf(5), which allow to set defaults for the
 default class or other custom user classes), and users may be added to
 classes (a passwd field is reserved for that).  There also are sysctls,
 such as kern.maxfiles, and of course per-process sysctl rlimit knobs...

 But although all of it can be configured, the main issue is that it's
 always by surprise that we notice these are too low, and some
 instability or other issues may occur until an administrator notices
 some limits are too restrictive.

 There's also the unfortunate reality that many people develop for
 Linux, and they expect the limits (or lack theirof) which are common on
 their favorite distribution.  It'd be nice to survey the various common
 default limits and evaluate what we consider reasonable...
 -- 
 Matt

>Unformatted:

Home	PR Database Search