On 04/13/2013 11:43 AM, Anders Lindborg wrote:
We have used PowerDNS a while ago and it was quite speedy, but I think Unbund outperforms just about anything. Could it perhaps be more efficient regarding cache management as well? I have seen configurations in the thread with many gigabytes of cache, so how does it work for you all?
I run Unbound with rrset-cache-size = msg-cache-size = 8000m, as I found they grew fairly parallel. Filling up those 8GBs of cache took a long while too (several days at 30-40k qps), so without having looked too much into the details, it should give heaps and bounds more caching than is really needed to make the long tail (rare, but high-TTL queries) happy. Unbound is run with 4 threads, which makes it run comfortably even in failover (double or triple load conditions). I started out with 16, but it ended up doing more thread work than real work. Some other notes: Beware of Unbound 1.4.17! We've been hit maybe 5-10 times by this bug over the last year or so: http://unbound.nlnetlabs.nl/pipermail/unbound-users/2012-July/002493.html We work around it by monitoring the Unbound process with monit, and I'll still do that for newer versions since the last message in the thread ended up in a sort of cliffhanger with no conclusion. You're doing proper failover and balancing, naturally, but make sure the processes are kept alive. Also, don't assume that users and stub resolvers will cleverly start using your secondary resolver if the first one is unavailable (libc will try the primary resolver first on every lookup, regardless of any 'rotate' option in resolv.conf, for example) -- always, alway, always keep your primary available. For further tweaking, you can consider enabling Unbound's prefetch option, although the impact of leaving it disabled could be considered negligible. sven _______________________________________________ Unbound-users mailing list [email protected] http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
