Date: Tue, 15 Jul 2008 16:09:17 -0700 From: Bakul Shah <bakul@bitblocks.com> To: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org> Cc: freebsd-net@freebsd.org, Kris Kennaway <kris@FreeBSD.org>, Thomas Vogt <freebsdlists@bsdunix.ch> Subject: Re: too many open file descriptors messages since bind 9.4.2-P1 (port dns94) Message-ID: <20080715230917.DAC3B5B46@mail.bitblocks.com> In-Reply-To: Your message of "Tue, 15 Jul 2008 15:39:09 PDT." <m2skuag4c2.wl%Jinmei_Tatuya@isc.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 15 Jul 2008 15:39:09 PDT JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <Jinmei_Tatuya@isc.org> wrote: > At Tue, 15 Jul 2008 15:12:31 -0700, > Bakul Shah <bakul@bitblocks.com> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080715230917.DAC3B5B46>