Timeouts during cache cleaning and zone collection
none at nospam.none
Fri Jun 24 12:00:36 UTC 2005
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?
>> 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.
More information about the bind-users