Subject: Re: increasing FD_SETSIZE to 1024 or 2048?
To: None <Havard.Eidnes@runit.sintef.no>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 07/08/2000 15:27:27
In message <20000708180256W.email@example.com>,
>Are you saying that all your requestors each use their own
>permanent TCP socket towards the name server providing recursive
>lookup service? Is there a particular reason that the resolver
>clients can't use UDP instead? If you did, I would think that the
>FD_SETSIZE issue on the default named goes away.
No, the requestors are using UDP and the standard netbsd resolver
(which means one process per requestor).
As to why increasing FD_SETSIZE (and doing "limit 1024" or "limit
2048" or whatever i have today) increases thourghput: i have no idea.
>This of course won't solve all the other more generic problems in
>bind8 e.g. related to handling many outstanding queries, but that's
>a different kettle of fish.
Well, it *seems* to increase the number of outstanding queries I can
handle by a small factor (say, about 3x). Again, i have no idea (yet)
why that is.
Upping named's FD_SETSIZE is (of course) a different issue from
whether FD_SETSIZE == 256 is a good or adequate default limit for
precompiled binaries (apps and libraries) on all the machines we support.