Date: Mon, 13 Apr 2015 20:15:30 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: arch@freebsd.org, Slawa Olhovchenkov <slw@zxy.spb.ru> Subject: Re: default file descriptor limit ? Message-ID: <20150413194709.L1619@besplex.bde.org> In-Reply-To: <97929.1428914379@critter.freebsd.dk> References: <78759.1428912996@critter.freebsd.dk> <79209.1428913320@critter.freebsd.dk> <20150413083159.GN1394@zxy.spb.ru> <97929.1428914379@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Apr 2015, Poul-Henning Kamp wrote: > -------- > In message <20150413083159.GN1394@zxy.spb.ru>, Slawa Olhovchenkov writes: > >>>> This wastes tons of pointless close system calls in programs which >>>> use the suboptimal but best practice: >>>> >>>> for (i = 3; i < sysconf(_SC_OPEN_MAX); i++) >>>> close(i); >>>> >>>> For reference Linux seems to default to 1024, leaving it up to >>>> massive server processes to increase the limit for themselves. >> >> This is typical only on startup, I think? > > No. This is mandatory whenever you spawn an sub process with less privilege. Not quite. sysconf() returns the soft rlimit. Privilege is not need to change the soft rlimit back and forth between 0 and the hard rlimit. >> May be now time to introduce new login class, for desktop users, [...] > > How about "now is the time to realize that very few processes need more > than a few tens of filedescriptors" ? > > If Linux can manage with a hardcoded default of 1024, so can we... RLIM_INFINITY seems reasonable for the hard limit and 1024 for the soft limit. Large auto-configed values like 400000 are insignificantly different from infinity anyway. They are per-process, so even the limits of 11000 on my small systems are also essentially infinite. There are also the kern.maxfilesperproc and kern.maxfiles limits. These are poorly implemented, starting with their default values. maxfilesperproc defaults to the same value as the rlimit. So a single process that allocates up to its rlimit makes it impossible for any other process, even privileged ones, to get anywhere near their rlimit. Some over-commit is needed, but not this much. This has hacks to let privileged processes allocate a few more descriptors provided priv. processes never over-commit. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150413194709.L1619>