From owner-freebsd-net@FreeBSD.ORG Tue Jul 15 23:09:19 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 459A31065674; Tue, 15 Jul 2008 23:09:19 +0000 (UTC) (envelope-from bakul@bitblocks.com) Received: from mail.bitblocks.com (bitblocks.com [64.142.15.60]) by mx1.freebsd.org (Postfix) with ESMTP id 0BE058FC21; Tue, 15 Jul 2008 23:09:18 +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 DAC3B5B46; Tue, 15 Jul 2008 16:09:17 -0700 (PDT) To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= In-reply-to: Your message of "Tue, 15 Jul 2008 15:39:09 PDT." Date: Tue, 15 Jul 2008 16:09:17 -0700 From: Bakul Shah Message-Id: <20080715230917.DAC3B5B46@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 23:09:19 -0000 On Tue, 15 Jul 2008 15:39:09 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote: > At Tue, 15 Jul 2008 15:12:31 -0700, > Bakul Shah wrote: > > > > 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). > > I've not played with poll(2) in BIND9, but as far as I understand it, > it doesn't solve the fundamental overhead issue here. For example, > the application should examine all possible descriptors even if only a > few of them are readable. IIRC, when poll() returns n, you only look at the first n values in the pollfd array so it is a win when you expect a very small number of fds to be ready. In the select case you have to test the bit array until you see the last ready fd. > Anyway, since this is a FreeBSD specific list, I believe we can safely > assume the existence of kqueue, unless we are talking about a very old > version:-) Presumably kqueue has a lower cpu usage until the system gets loaded at which point polling might win.