Mark Andrews wrote:
> In message <491A19E3.4050607@chrysler.com>, Kevin Darcy writes:
>
>> Mark Andrews wrote:
>>
>>> In message <491A0864.70105@chrysler.com>, Kevin Darcy writes:
>>>
>>>
>>>> Jonathan Petersson wrote:
>>>>
>>>>
>>>>> Hi,
>>>>> Is there some statement that you can give that triggers bind to check out
>>>>>

>> a
>>
>>>>> current log-file when a new day occurs. I'm currently using the size optio
>>>>>

>> n
>>
>>>>> but it would be useful if you could have 1 file per day instead.
>>>>>
>>>>> If not I guess I'll have to do a cronjob.
>>>>>
>>>>>
>>>>>
>>>> Yeah, it would be nice if there were an rndc "logroll" command.
>>>>
>>>> For that matter, it would be nice to have a cache-cleaning command in
>>>> rndc as well, so that one could schedule that potentially-disruptive
>>>> activity for off-hours.
>>>>
>>>>
>>> rndc flush (clears the entire cache)
>>> rndc flushname (clears the given name)
>>>
>>>

>> clear != clean. I'm talking about only deleting the expired entries. I
>> know about cleaning-interval, and it's a handy tunable, but in
>> high-performance environments sometimes one needs uneven intervals or to
>> skip intervals sometimes (e.g. during month-end processing or whatever).
>> An rndc command for "manual" cleaning would give more fine-grained control.
>>
>> - Kevin
>>

>
> Just set the cache size and named do extra cleaning.
>
>

Obviously I'm not making myself very clear.

I'm talking about a box with plenty of memory available, where a lot of
the commonly-accessed data persists in cache, and the goal is to make
the turnaround time for queries of this cached data to be
_consistently_short_. A time-sensitive app might be negatively impacted
if named decides to kick off a cleaning operation while the app is
trying to resolve a bunch of names.

One option is to turn off cache-cleaning altogether. But eventually, I
would think, the memory structures would accumulate junk to the point
that performance would be impacted anyway. There should be a "sweet
spot" -- enough cleaning to keep cache fetches efficient, but not so
much as to give inconsistent query turnaround times because of
cache-cleaning overhead. Being able to schedule cleaning for times of
the day/week/month that are known to be low-volume or low-impact (which
aren't necessarily the same thing), would be ideal.

In any case, I just threw that out there as a "would be nice" idea. We
don't have any pressing requirement for this, and I'm not aware that
anyone else does either...


- Kevin