[Unbound-users] Improve avg response times

Mon Jul 9 16:37:40 UTC 2012

Hi Stephan,

Thanks. It indeed seems like LRU is happening. The RAM number was a typo - I
had 6.5GBytes (not Mbytes) free while even at peak load unbound was taking
<50-100Mbytes of RAM across all of its components. 

With sufficient memory and my setup below, can you see why least-recently
used entries are forced to be purged from cache? 

To work-around this behavior, I am running a continuous scan instead of an
hourly cronjob so my LRU entries get re-queried every 25mins instead of
every 60mins. With a 80% prefetch, 3600 cache-min-ttl, I am now able to get
40-80ms avg response times mostly from the cache. However, the down side now
is a steady 40-50% cpu load given all the scanning. I definitely have a very
inefficient setup right now to get my response times down to ~50ms.

Would love to see how else I can keep my oldest entries from being purged
from cache if memory and cache-min-ttl are large enough.

Vinay.

From: Stephan Lagerholm [mailto:stephan.lagerholm at secure64.com] 
Sent: Monday, July 09, 2012 6:35 AM
To: vinay3 at justemail.net; unbound-users at unbound.net
Subject: RE: [Unbound-users] Improve avg response times

Hi Vinay,

The unbound name server is using the Least resent used (LRU) algorithm to
decide what to throw out when the cache gets full. There is no 'garbage
collection' like in Bind. Doing this like unbound does it should be somewhat
faster and nicer to the processor, but the flip-side is that prefetching is
not working that very well (good stuff might get thrown out when
prefetching). 

I notice that you don't have that much memory. Maybe your memory is only
large enough for say 10 minutes of cached entries. If nobody is asking for
www.utorrent.com during those 10 minutes, then it will be kicked out. Try to
increase your cache memory size or ask more often for the site that you want
to make sure you have cached.

/Stephan

From: unbound-users-bounces at unbound.net
[mailto:unbound-users-bounces at unbound.net] On Behalf Of vinay3 at justemail.net
Sent: Saturday, July 07, 2012 1:55 PM
To: unbound-users at unbound.net
Subject: Re: [Unbound-users] Improve avg response times

I tried using a prefetch trigger at 90% instead of 10% (intentionally
inefficient) and a cache-min-ttl of 5400 so that an hourly scan is
guaranteed to find a cached entry from the last scan and will also reset
it's TTL back to 5400 by forcing a new iteration.

If I do a new namebench run, I still get a 150ms+ avg response time and I
see several responses that have a TTL of 5400 meaning they were cachemisses.

blog.sina.com.cn.

A

814.8959

5400

2

blogx.sina.com.cn. -> 218.30.115.254

www.utorrent.com.

A

203.908

5400

1

67.215.233.130

in.youtube.com.

A

29.46731

2982

2

youtube-ui.l.google.com. -> 74.125.224.46, 74.125.224.32, 74.125.224.33,
74.125.224.34, 74.125.224.35, 74.125.224.36, 74.125.224.37, 74.125.224.38,
74.125.224.39, 74.125.224.40, 74.125.224.41

search.mywebsearch.com.

A

72.6796

2985

2

www154.mywebsearch.com. -> 74.113.233.48

wenwen.soso.com.

A

296.7475

5236

1

202.55.10.153

www.uploading.com.

A

26.0509

3007

1

195.191.207.40

www.ebay.com.

A

31.4418

5400

1

66.135.200.161, 66.135.200.181, 66.135.210.61, 66.135.210.181,
66.211.181.161, 66.211.181.181

So this is appearing like unexpected behavior to me: If www.utorrent.com was
scanned less than an hour ago and was supposed to be cached for 5400
seconds, why would a random scan like the one above find it flushed out of
the cache (5400 TTL) and requiring an iteration (203.9 msecs response time)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.nlnetlabs.nl/pipermail/unbound-users/attachments/20120709/0a26dae6/attachment.htm>