request drops in BIND?

Paul Vixie paul at vix.com
Fri May 14 17:02:29 UTC 2004


> Yes. I saw that code. BIND drops requests after handling 500 requests
> in the udp buffer.

actually, it only handles the responses in the udp buffer, requests really
are just dropped.

> 500 is roughly 32KB(~= 64*500), which makes sense when the buffer size
> is 32KB.  But what if the buffer is bigger? My linux stack says the
> default buffer size is 64KB.  You might end up dropping 500 requests
> silently.

since this only happens when a synchronous event takes a long time, and
not during normal query processing, the more important metrics are "how
many transactions can you perform every second?" and "how many
transactions are you asked to perform every second?"

> One question. Does BIND use the same udp socket to handle remote server
> queries?

yes.  of necessity, a udp socket has a port number, and the responses will
come in on the same socket where the requests were made.

> I think I saw some code to read data from the udp buffer and to tell
> if it's a request or response.  If the same buffer is shared to handle
> remote server queries(like queries to root servers/gTDL servers) as
> well as the requests from clients, that would lead to buffer overflow
> even faster.  (300 bytes of response * 200 = 60K, so 300 such
> responses would easily overflow the buffer)

the important thing is that most of the time when the udp socket buffer 
becomes or remains nonempty, we read the queries and generate responses
immediately.

> It's on Linux 7.2, Compaq au600, 1GB. I don't know the memory read
> bandwidth of this machine.

please run "lmbench" and verify that your memory read performance is at
least 400Mbyte/sec, or you will not be able to benefit from that CPU speed.
(BIND is memory-read bottlenecked, and then it's system-call bottlenecked,
and so CPU speed is only a tertiary factor to BIND's performance.)

> My test scheme is to send that many requests at once, and wait and record
> the responses for 10 seconds.

in that case you're really measuring the depth of various queues/buffers,
and not the sustained performance (in transactions per second) of the system.

> One interesting behavior is that the first timee(I do this 10 times)
> gets always more responses than the subsequent ones.  I don't know why
> at this point.

i can't think of a reason.  once the udp kernel buffer is empty, and once
BIND has returned to an idle state, subsequent runs should have the same
burst depth.  i guess it's possible that heap fragmentation could be 
affecting you, but because of the memget/memput model employed in BIND8,
that should produce the opposite effect (due to slabbing and reuse.)


More information about the bind-users mailing list