[Unbound-users] Query problems with multi-threaded server
wouter at NLnetLabs.nl
Fri Jan 16 13:12:24 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
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
> The ulimit of my servers are:
> ulimit -n: 100000
> ulimit -m unlimited
> ulimit -v unlimited
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Unbound-users