Zitat von Jaco Lesch <[email protected]>:
Andreas/Wouter
Thanks for your insight and feedback.
With the info/ideas from Andreas I have amended the parameters in
the unbound.conf as follows:
# Optimise settings
num-threads: 64
#
msg-cache-slabs: 64
rrset-cache-slabs: 64
infra-cache-slabs: 64
key-cache-slabs: 64
rrset-cache-size: 1024m
msg-cache-size: 512m
infra-cache-numhosts: 100000
#
# Larger socket buffer
# For Solaris 11 set the following UDP parameter 1st:
# 'ipadm set-prop -p max_buf=8388608 udp'
so-rcvbuf: 8m
so-sndbuf: 8m
#
outgoing-range: 32768
num-queries-per-thread: 1024
This improved performance significantly with a jump from 3600 qps to
6200 qps and the system was not sluggish with this "workload" at
all. The magic seems to have been the combination of
"outgoing-range" and "num-queries-per-thread", the system load did
drop from 28 to around 21 directly after this change.
I also did recompile with Wouter's suggestion of using only Solaris
threads, but the gain was very little if any. Again this is
something to keep in mind for the future? Also stayed with the 64
threads for now, but at a later stage will test again at a full 128
threads, when I feel brave again.
Hello
as said i doubt you will gain much with a high (>>4) number of
threads. Threads are used to prevent resovler stall if all slots
(num-queries-per-thread) are busy (data on the fly). With 64 threads
you have the potential of 64k not yet answered queries hammering your
upstream. I would suggest you start with some really low value like 4
threads and see if raising this value will raise the qps tested.
Regards
Andreas
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
