Timeouts during cache cleaning and zone collection

JINMEI Tatuya / 神明達哉 jinmei at isl.rdc.toshiba.co.jp
Thu Jun 23 19:33:06 UTC 2005


>>>>> 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'.

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.

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



More information about the bind-users mailing list