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.
Regards
On 05/02/2013 15:04, [email protected] wrote:
Zitat von Jaco Lesch <[email protected]>:
Andreas
Here is some info regarding your questions:-
The portion of unbound.conf pertaining to the "HowTo Optimise":
# Optimise settings
num-threads: 112
#
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: 8192
num-queries-per-thread: 4096
Hmm, i would lower "num-queries-per-thread" or leave default and raise
the "outgoing-range" if the OS permits. From my knowledge the
outgoing-range limit the max. number of open sockets for upstream
queries and should be roughly num-threads * num-queries-per-thread, no?
You could also try to lower the num-threads, maybe you have already
missed the sweet-point with best balance between concurrency and max
out the hardware.
Regards
Andreas
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
--
---
Jaco Lesch
SAIX HLS
Email: [email protected]
_______________________________________________
Unbound-users mailing list
[email protected]
http://unbound.nlnetlabs.nl/mailman/listinfo/unbound-users
