Generic reasons for recursive performance not to peg CPU?

[Phil Mayers]

On 13/01/14 01:16, Doug Barton wrote:
> Howdy,
>
> Without going into too much detail, doing some performance testing and
> am seeing a weird result. On the same systems authoritative queries will
> happily peg the CPU. However when running recursive queries (with a
> small zone, all data cached before testing) the CPU never gets above
> 80%. The disk is nearly inactive on both systems, and there is no
> swapping. Using BIND 9.9.4.
>
> Is there perhaps something obvious I'm overlooking here? Any suggestions
> are welcome.

I'm wondering if it's something tediously low-level like scheduler, 
issues relating to concurrency/locking of the cache, and so on. 
Presumably bind has some method to protect the cache from simultaneous 
updates that requires some degree of locking - perhaps you're loading it 
to a degree that you're bumping into lock waiting?

What's the (relative) size of the auth vs. pre-loaded recursive cache?

A generic CPU tracing tool (e.g. "perf" under Linux) might be able to 
tell you the hotspots in the two cases, and any differences might be 
instructive.