Hi,
I'm running unbound with 4 separate threads and I notice that sometimes the same query
returns ok and sometimes returns error.
I understood that with 4 threads each one have a separate cache. Is this correct ?
So maybe one cache has the data and other couldn't get it.
Normally the query below returns ok:
You're compiling it with "--without-pthreads --without-solaris-threads"
which disables threading. Each Unbound process will have it's own cache.
Hope that helps,
Haw
Hi,
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 ?
Also I understand that the commands from unbound-control (flush, lookup, etc) are sent to all the threads.
Correct ?
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.
The ulimit of my servers are:
ulimit -n: 100000
ulimit -m unlimited
ulimit -v unlimited
Thanks,
Roberto
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.
OK
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
threading.
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,
Wouter