From owner-freebsd-arch@FreeBSD.ORG Mon Apr 13 10:15:37 2015 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 57107236 for ; Mon, 13 Apr 2015 10:15:37 +0000 (UTC) Received: from mail104.syd.optusnet.com.au (mail104.syd.optusnet.com.au [211.29.132.246]) by mx1.freebsd.org (Postfix) with ESMTP id 17DAD1000 for ; Mon, 13 Apr 2015 10:15:36 +0000 (UTC) Received: from c211-30-166-197.carlnfd1.nsw.optusnet.com.au (c211-30-166-197.carlnfd1.nsw.optusnet.com.au [211.30.166.197]) by mail104.syd.optusnet.com.au (Postfix) with ESMTPS id 92B4A4273C0; Mon, 13 Apr 2015 20:15:31 +1000 (AEST) Date: Mon, 13 Apr 2015 20:15:30 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: default file descriptor limit ? In-Reply-To: <97929.1428914379@critter.freebsd.dk> Message-ID: <20150413194709.L1619@besplex.bde.org> References: <78759.1428912996@critter.freebsd.dk> <79209.1428913320@critter.freebsd.dk> <20150413083159.GN1394@zxy.spb.ru> <97929.1428914379@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=ZuzUdbLG c=1 sm=1 tr=0 a=KA6XNC2GZCFrdESI5ZmdjQ==:117 a=PO7r1zJSAAAA:8 a=EA5itrwUPoEA:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=KawIFhhbAAAA:8 a=odNzpWaeI0nUqWQo6FwA:9 a=CjuIK1q_8ugA:10 Cc: arch@freebsd.org, Slawa Olhovchenkov X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Apr 2015 10:15:37 -0000 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