[Pdns-users] CPU consumption of pdns_recursor

[Remi Gacogne]

On 4/6/21 4:18 PM, Nejedlo, Mark via Pdns-users wrote:
> Would additional distributor threads really cause additional worker CPU usage?

That could happen if they have to fight for the incoming socket. Do you 
have reuseport=yes in your configuration?

> Does the maintenance function block the worker while it's running?

Yes.

>> I see that XPF is enabled between dnsdist and the recursor, which likely
>> kills the recursor's packet cache. That might explain the bad
>> performance results.
> 
> Even with a short edns-subnet-whitelist?

I'm afraid so, yes, and since some of your responses depends on the 
client IP (EDNS Client Subnet is enabled for some domains) you can't 
really enable the packet cache in dnsdist, unless you know for sure that 
only a few domains are using EDNS Client Subnet, and that there is no 
CNAME to them from other domains. Then you could perhaps enable the 
packet cache in dnsdist and disable it for these domains only.

Do you really XPF, by the way? You are passing the initial client IP in 
EDNS Client Subnet already, so that might be enough?

> Both 4.4/5 and proxy protocol were on my radar, but my priority was to address the CPU usage.  If there's performance gains to be had in upgrading, I can certainly do that.  Is 4.5GA likely to happen soon?

The proxy protocol adds a header outside of the DNS payload, so it would 
not kill your packet cache. If you get rid of EDNS Client Subnet and XPF 
between dnsdist and the recursor so you should get much better performance.
Even if you need to keep EDNS Client Subnet between dnsdist and the 
recursor, you could then try enabling dnsdist's packet cache with the 
EDNS zero scope feature [1] which let dnsdist know when it can cache an 
answer for all clients.

[1]: 
https://dnsdist.org/reference/config.html?highlight=disableZeroScope#newServer

-- 
Remi