From owner-freebsd-stable@FreeBSD.ORG Sat Sep 27 03:02:09 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 250391065690 for ; Sat, 27 Sep 2008 03:02:09 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from QMTA08.emeryville.ca.mail.comcast.net (qmta08.emeryville.ca.mail.comcast.net [76.96.30.80]) by mx1.freebsd.org (Postfix) with ESMTP id 09B0B8FC19 for ; Sat, 27 Sep 2008 03:02:08 +0000 (UTC) (envelope-from jdc@koitsu.dyndns.org) Received: from OMTA09.emeryville.ca.mail.comcast.net ([76.96.30.20]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id KcRK1a00R0S2fkCA8f28pn; Sat, 27 Sep 2008 03:02:08 +0000 Received: from koitsu.dyndns.org ([67.180.253.227]) by OMTA09.emeryville.ca.mail.comcast.net with comcast id Kf241a00K4v8bD78Vf25lo; Sat, 27 Sep 2008 03:02:05 +0000 X-Authority-Analysis: v=1.0 c=1 a=6I5d2MoRAAAA:8 a=QycZ5dHgAAAA:8 a=Pd3Si49nVNFPp4pYRB4A:9 a=HRHXUg4pcuvBOhoxypwZtxG2lz8A:4 a=EoioJ0NPDVgA:10 a=LY0hPdMaydYA:10 Received: by icarus.home.lan (Postfix, from userid 1000) id CBE34C9432; Fri, 26 Sep 2008 20:02:04 -0700 (PDT) Date: Fri, 26 Sep 2008 20:02:04 -0700 From: Jeremy Chadwick To: Aristedes Maniatis Message-ID: <20080927030204.GB40195@icarus.home.lan> References: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <98425339-23F8-4A90-8CF1-2E85DD82D857@ish.com.au> User-Agent: Mutt/1.5.18 (2008-05-17) Cc: freebsd-stable Stable Subject: Re: sysctl maxfiles X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Sep 2008 03:02:09 -0000 On Sat, Sep 27, 2008 at 11:10:01AM +1000, Aristedes Maniatis wrote: > By default FreeBSD 7.0 shipped with the sysctls set to: > > kern.maxfiles: 12328 > kern.maxfilesperproc: 11095 > > We recently bumped up against these limits in an unfortunate way and we > are going to raise them. I have some questions: > > * why are the numbers set the way they are? They aren't round numbers, > they aren't powers of 2. But they were arrived at somehow with planning > and thought presumably, so when I increase them I'd like to know a bit > more about why these numbers were chosen. The values are calculated when the kernel is loaded, based on many other parameters; you won't find "12328" hard-coded anywhere in the kernel source, for example. The Handbook goes over this fact: http://www.freebsd.org/doc/en/books/handbook/configtuning-kernel-limits.html By the way, DO NOT let the term "maxusers" make you think that has something to do with the number of users which can be logged in simultaneously or added to a box. It has nothing to do with that. Anyway, I'd like to know why you have so many fds open simultaneously in the first place. We're talking over 11,000 fds actively open at once -- this is not a small number. What exactly is this machine doing? Are you absolutely certain tuning this higher is justified? Have you looked into the possibility that you have a program which is exhausting fds by not closing them when finished? (Yes, this is quite common; I've seen bad Java code cause this problem on Solaris.) > * why are the numbers so close together? Surely there should be more gap > between max files per process and the max files for the whole system. > What happens is that with one runaway broken process is that it hits > 11095 and the 1233 files left for everything else is not enough (on many > servers) to allow the admin to login using ssh. That gets very ugly very > quickly. Others will have to comment on this. > * Under OSX (both server and client), these numbers are 12288 and 10240. > A bit more of a gap, but not terribly different to FreeBSD. Still > interesting that someone changed these numbers just slightly. OS X isn't based on FreeBSD 7. The calculation logic has changed over time. > * why do these controls exist at all? That is, if they were set to > infinite what part of the system would be exhausted by a runaway process > which kept opening files? Would the kernel run out of memory? What memory > setting would be relevant here? I don't want to set maxfiles too high and > then run out of some other resource which this maxfiles was protecting. You're asking for trouble setting these values to the equivalent of unlimited. Instead of asking "what would happen", you should be asking "why would I need to do that". Regarding memory implications, the Handbook goes over it. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB |