Hello.
I am very new to unbound. I've used BIND for years, though, so I understand the DNS concepts. Mind if I ask a few questions?
Below is my unbound configuration and farther below are the stats from an 18-hour run of unbound. I am running RHEL 5.7 on a dual-core CPU with SMT enabled (i.e. the OS sees 4 processors) with plenty of RAM. Unbound was built against the current versions of it's dependencies, except for version 2.5 of GLibC.
1. I built unbound with the libevent library because I read that it improved scalability, which seemed reasonable given that I can run 4 threads simultaneously. After 18 hours with what I think is a representative load I get this:
info: server stats for thread 0: 622 queries, 98 answers from cache, 524 recursions, 10 prefetch
info: server stats for thread 1: 18161 queries, 3186 answers from cache, 14975 recursions, 265 prefetch
info: server stats for thread 2: 15963 queries, 2746 answers from cache, 13217 recursions, 248 prefetch
info: server stats for thread 3: 1064 queries, 179 answers from cache, 885 recursions, 20 prefetch
info: server stats for thread 0: requestlist max 6 avg 0.153558 exceeded 0 jostled 0
info: server stats for thread 1: requestlist max 11 avg 0.594094 exceeded 0 jostled 0
info: server stats for thread 2: requestlist max 11 avg 0.496547 exceeded 0 jostled 0
info: server stats for thread 3: requestlist max 3 avg 0.109392 exceeded 0 jostled 0
It looks to me like 2 of unbound's 4 threads are superfluous. Given this load (roughly 2000 queries per hour) I wonder if I would be better off giving up on the libevent config and just running 2 threads in a forked configuration. Opinions?
2. Of the roughly 26,000 recursions done, 11 of them took over 512 seconds (1 over 1024 seconds!). I realize that 11 out of 26,000 is a tiny percentage, but I'm concerned that unbound didn't give up on these recursions earlier. Does unbound impose a max recursion time, or do stuck recursions linger until the program is terminated?
Thank you.