Timeouts during cache cleaning and zone collection

[Nod]

On Fri, 24 Jun 2005 04:33:06 +0900, JINMEI Tatuya / $B?@L at C#:H(B
<jinmei at isl.rdc.toshiba.co.jp> wrote:

>>>>>> On Wed, 22 Jun 2005 23:40:57 GMT, 
>>>>>> none at nospam.none (Nod) said:
>
>>> Also, didn't you get *any* responses during the cache cleaning?  Or
>>> did you still see some responses (as well as no-answers)?  In my
>>> understanding, named should still be able to respond to queries even
>>> during the cache cleaning while it can drop some of the queries due to
>>> the additional cleaning task.
>
>> The server would respond to an 'rndc status', and showed about 30-40 recursive
>> clients. For a server normally serving 600+, I'd consider this to be
>> non-responsive. If it was answering DNS requests, I couldn't tell.
>
>Okay, so what's actually happening is:
>
>- if you execute 'rndc status' during the cleaning period, 'recursive
>  clients' are 30-40.
>- if you execute 'rndc status' at other timing, 'recursive clients'
>  are usually over 600.
>
>Is my understanding correct?
Correct.

>> I'll look into it, however it seems like the cleaning method itself is
>> intrinsically flawed. As I see a cache, once new data comes into a full cache,
>> the old data should get 'pushed' out, instead of a period (garbage?) cleanup. If
>> I'm misunderstanding this, feel free to correct.
>
>Depending on the meaning of 'full cache', 'new data' or 'the old
>data'.  When you specify max-cache-size, a busy cache will eventually
>be 'full' in that the memory for the cache reaches the specified
>maximum.  Then some of the existing entries in the cache will be
>removed ('pushed out') so that the cache can contain new entries with
>the memory consumption under the maximum.  This procedure runs
>separately from the periodic cleaning, so we could say this 'instead
>of a period cleanup'.
It appears that when the cache is full, the cleaner runs anyway. I didn't see a
seperate log entry that looked any different.

>
>So, if you can live with a moderate setting of max-cache-size (I'm
>afraid 16 megs are way too small for a busy cache server), that would
>be the solution for you. (I guess in this case you don't have to set
>the cleaning interval to such a small value as 1 minute).  Relying on
>a small max-cache-size has a different drawback, though: it tends to
>make the CPU busy as you saw.
Sure does. 16 megs is way too small, but it does work around the lockups.

>
>Whether or not the cleaning method is intrinsically flawed (even if it
>is, ISC would need time to fix it and we'd need a workaround in the
>mean time), I'm still interested in how the change of
>DNS_CACHE_CLEANERINCREMENT works.  So it would be great if you could
>give it a try.  You might also want to modify the cleaning interval to
>a smaller value (say, 20 minutes).  A moderate combination of
>DNS_CACHE_CLEANERINCREMENT and the cleaning interval may reasonably
>mitigate the inactivity.
>
>					JINMEI, Tatuya
>					Communication Platform Lab.
>					Corporate R&D Center, Toshiba Corp.
>					jinmei at isl.rdc.toshiba.co.jp
>
I'll take a look.