[Unbound-users] TTL over cache-chunks
Filipe Cifali
cifali.filipe at gmail.com
Mon Sep 1 14:00:18 UTC 2014
I'm seeing a behavior that I'm not sure is normal or I don't really
understood the meaning of cache-chunks.
Using multi-threads, is recommended to use the same number of chunks, based
on my tests, each chunk has is own cache for TTL and requests.
So, if I want to store cache only, I would need to use only one chunk of
cache. Is that correct?
In a multi-resolver scenario, I do like to put one unbound in front of
backend unbounds to cache de queries, but that would make him very
requested, that's why I searched about thread vs fork mode and was thinking
about using fork(even requiring more hardware, that's for the best
performance).
But I think I'm missing something, my configuration is basically:
E5405 8xCPU 2.00 Ghz
8 GB RAM
server:
verbosity: 1
num-threads: 1
msg-cache-slabs: 1
rrset-cache-slabs: 1
infra-cache-slabs: 1
key-cache-slabs: 1
outgoing-range: 8192
num-queries-per-thread: 1024
rrset-cache-size: 2g
msg-cache-size: 1g
key-cache-size: 1g
neg-cache-size: 2g
cache-min-ttl: 7200
cache-max-ttl: 86400
infra-host-ttl: 3600
infra-cache-slabs: 8
infra-cache-numhosts: 100000
port: 53
do-ip4: yes
do-ip6: no
do-udp: yes
do-tcp: yes
access-control: 127.0.0.0/8 allow
username: "unbound"
directory: "/etc/unbound"
logfile: "logs/unbound.log"
use-syslog: no
log-queries: no
pidfile: "/var/run/unbound.pid"
hide-identity: yes
hide-version: yes
identity: ""
version: ""
harden-short-bufsize: no
harden-large-queries: no
harden-glue: yes
harden-dnssec-stripped: yes
harden-below-nxdomain: no
harden-referral-path: no
use-caps-for-id: yes
prefetch: yes
prefetch-key: yes
rrset-roundrobin: yes
minimal-responses: yes
include: "/etc/unbound/local-zone.conf"
python:
remote-control:
control-enable: yes
control-interface: 127.0.0.1
--
[ ]'s
Filipe Cifali Stangler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20140901/c691537a/attachment.htm>
More information about the Unbound-users
mailing list