Maintained by: NLnet Labs

[Unbound-users] Query problems with multi-threaded server

W.C.A. Wijngaards
Fri Jan 16 14:12:24 CET 2009

Hash: SHA1

Hi Roberto,

Roberto Adler wrote:
> I couldn't test with verbosity 4 because the server can't handle it,
> even for a short time.
> So I set up a new server just to test but the problem didn't occur.
> I'll try to make more tests later.


> A question:
> Since with separate threads we have separate caches, and one cache could
> have the answer and
> other could be negative (unusual but can occur), how the command
> "unbound-control dump_cache"
> would work ?

dump_cache only works on the first cache in that case.
Also lookup works only on the first cache.
And load_cache would work on the first cache only.

> Also I understand that the commands from unbound-control (flush, lookup,
> etc) are sent to all the threads.
> Correct ?

Yes they are, with only a couple exceptions when you compiled without

> I compiled unbound with separate threads because with libevent I noticed
> that the threads are geting uneven
> load. My main server receives 150k qry/min (9.000.000 qry/hr). With
> libevent one thread deals with, for example,
> 70 % of the queries and the other three 10% each.
> With separate threads each one manage 25% of tthe queries.

This is likely not a problem at all.

I think the libevent case where one thread does 70% of the work is
caused by the OS and its thread handling.  The reason not all threads
are working is because there is not enough work to use them all.

(if you have 4 processors and enough load, the OS would use all
threads). It may even be more optimal (for the OS) to use one thread
more considering cpu-cache coherency or virtual memory paging. OS makers
spend lots of time in their process and thread management design; linux
2.4 and 2.6 are very different I believe and Solaris touts superior
thread handling as a feature.

The OS handles processes differently, hence the 25% in the case of
unthreaded use.

> The ulimit of my servers are:
> ulimit -n:      100000
> ulimit -m       unlimited
> ulimit -v       unlimited

Looks good,

Best regards,
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -