high availiblity DNS
Ramin K
ramin at badapple.net
Tue Jun 27 02:33:05 UTC 2000
At 09:19 PM 6/26/00 -0400, Alan J Rosenthal wrote:
>Ramin K <ramin at badapple.net> writes:
> >Availability, I think we can handle internally
>
>Well, I spoke of availability because you said "high availability DNS" (see
>subject line). Anyway though, do you truly have sufficiently redundant
>connection to the internet that availability can be handled internally?
>This is unusual (but not unheard of).
Maybe high-volume DNS is a better subject line?
Without going into a lot of detail, yes. :)
To further define the problem, the system is for customers, who are dialup
users and don't have a lot of "of the fly" ability for what DNS servers
they use.
> >what's bothering me is the sheer volume of requests we need to keep up with.
> >... We are already seeing drops
>
>I'm just saying that I don't think multiple named processes on one
>single-CPU machine will help. I don't see any realistic analysis of where
>the bottleneck is which would cause multiple named processes on the same
>machine to help. They'll take *more* CPU time (same CPU time for each
>request plus new context switching overhead), they'll take *more* memory,
>they'll take the *same* amount of network bandwidth, they'll put the *same*
>load on the machine's network interface hardware (e.g. ethernet card).
>You need to throw either more CPUs at the problem, or more networks, or,
>most likely, both. Your message may imply that you have more CPUs in mind
>(but not more networks). My hunch is that this is not the bottleneck,
>but I could be wrong.
Network bandwidth for I'd think just about anything, but a root name server
is negligible from what my bandwidth graphs show and some conservative
extrapolation.
RAM is far easier to add then more machines. Bind takes roughly 150 MB.
Round to 200 and I can still run 4 instances in a gig.
CPU is questionable. Bind is using 10% on the CPU load using top. I'd think
that running a 4 copies would be possible and not much of a strain even
with the overhead of extra processes.
From the numbers above it seems silly to buy lots of machines when I can
use the ones I have to their capacity. Assuming none of the above are the
limiting factors for named performance it would appear that named itself is
the issue. Bind is not multi threaded, we're seeing lots of resource
unavailable type errors because of the volume of requests. From what I
observed on my own systems, running multiple copies of Bind seemed to be
the way to go.
Ramin
_____NetZero Free Internet Access and Email______
http://www.netzero.net/download/index.html
More information about the bind-users
mailing list