From owner-freebsd-net@FreeBSD.ORG Tue Jul 15 22:12:32 2008 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E3A47106567A; Tue, 15 Jul 2008 22:12:32 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (ns1.bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id B5F158FC15; Tue, 15 Jul 2008 22:12:32 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from bitblocks.com (localhost.bitblocks.com [127.0.0.1]) by mail.bitblocks.com (Postfix) with ESMTP id E087C5B46; Tue, 15 Jul 2008 15:12:31 -0700 (PDT) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-reply-to: Your message of "Tue, 15 Jul 2008 14:18:41 PDT." Date: Tue, 15 Jul 2008 15:12:31 -0700 From: Bakul Shah Message-Id: <20080715221231.E087C5B46@mail.bitblocks.com> Cc: freebsd-net@freebsd.org, Kris Kennaway , Thomas Vogt Subject: Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jul 2008 22:12:33 -0000 On Tue, 15 Jul 2008 14:18:41 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > At Tue, 15 Jul 2008 23:09:30 +0200, > Kris Kennaway wrote: > > > > If that's regularly happening, I'm afraid recent P1 versions don't > > > handle that well, and recommend you try 9.4.3b2 ore 9.5.1b1. > > > > Or increase the number of file descriptors as a workaround, per my email :) > > Does FreeBSD allow an application to increase FD_SETSIZE (at its > compilation time)? I thought FD_SETSIZE defaults to 1024. Any > 9.x.y-P1 versions can only open FD_SETSIZE sockets, regardless of the > # FDs limit. $ cvs log /sys/kern/kern_generic.c ... revision 1.19 date: 1996/08/20 07:17:48; author: smpatel; state: Exp; lines: +43 -15 Remove the kernel FD_SETSIZE limit for select(). ... Unless things have changed, you can completely ignore FD_SETSIZE (& struct fd_set) and decide at runtime how many fds you want in a select read/write set (subject to the openfiles limit). Hmm... things have reverted back.... cvs blame -r1.71 /sys/kern/kern_generic.c # the earliest reversal I can find ... 1.71 (peter 07-Feb-01): * This is kinda bogus. We have fd limi ts, but that doesn't 1.71 (peter 07-Feb-01): * map too well to the size of the pfd[] array. Make sure 1.71 (peter 07-Feb-01): * we let the process use at least FD_SETSIZE entries. 1.71 (peter 07-Feb-01): * The specs say we only have to support OPEN_MAX entries (64). 1.71 (peter 07-Feb-01): */ 1.71 (peter 07-Feb-01): lim = min((int)p->p_rlimit[RLIMIT_NOFILE].rlim_cur, maxfilesperproc); 1.71 (peter 07-Feb-01): lim = min(lim, FD_SETSIZE); 1.71 (peter 07-Feb-01): if (nfds > lim) 1.71 (peter 07-Feb-01): return (EINVAL); Sigh.... This is a mistake. I don't see why a user is not allowed to select on all the fds he can open. The corresponding log indicates perhaps the author didn't know select used to work for # of fds > FD_SETSIZE. revision 1.71 date: 2001/02/07 23:28:01; author: peter; state: Exp; lines: +16 -8 The code I picked up from NetBSD in '97 had a nasty bug. It limited the index of the pollfd array to the number of fd's currently open, not the maximum number of fd's. ie: if you had 0,1,2 open, you could not use pollfd slots higher than 20. The specs say we only have to support OPEN_MAX [64] entries but we allow way more than that. > Besides, I guess that the P1 versions severely suffer from heavy > overhead of select(2) when it regularly opens more than 1000 sockets. > Even if 'too many open file' messages are gone, many users won't > accept the increased load due to the overhead. Beta versions use > kqueue, eliminating the fundamental overhead as well as the (too low) > limitation of # of descriptors. Or more portably you can use poll(2).