BIND memory statistics?

[Kevin Darcy]

D. Stussy wrote:
> "Kevin Darcy" <kcd at chrysler.com> wrote in message
> news:g5j3uk$2ivi$1 at sf1.isc.org...
>   
>> Matus UHLAR - fantomas wrote:
>>     
>>> Hello,
>>>
>>> I am currently running bind 9.5.0-p1 with cache limit turned off. I
>>>       
> would
>   
>>> like to turn it on, however It would be better with knowing how is
>>>       
> memory
>   
>>> used after some time (e.g. a week).
>>>
>>> I know how much of RRs do I have in cache but what are their average
>>>       
> TTL's,
>   
>>> were their TTL's when they were received and how often are they used?
>>>
>>> This should imho help me to know how effective the caching is, so I
>>>       
> could
>   
>>> tune memory usage. As I mentioned, my limit is currently turned off, but
>>> this could lead to excessive memory consumption of named process.
>>>
>>> I am also planning to turn on acache, but the problem is similar - I'd
>>>       
> like
>   
>>> to have an idea how effective it is...
>>>
>>> Can anyone advise me, if/how, is possible to do this?
>>>
>>>       
>> Well, you can look at the memory consumption of the process, and you can
>> use a sniffer to see how much traffic -- when you get cache misses -- is
>> going between your nameserver and the authoritative nameservers it's
>> querying on behalf of local clients, what else would you measure and,
>> once measured, how would you optimize? max-cache-ttl? max-ncache-ttl?
>> cleaning-interval? For BIND, usually the solution to memory problems is
>> to buy more memory; there's only so much you can twiddle in named.conf
>> to try and squeeze more performance from a memory-starved box.
>>     
>
> Or you could look at the web page that was added in 9.5.0.
>   
You mean the "statistics-channel" stuff? I haven't played with that yet.

 From the documentation, it looks like the "QryRecursion" counter, 
divided by the "Response" counter, might give a rough idea of cache hit 
ratio, assuming a pure caching-only instance. (I'm assuming here that 
queries don't show up in QryRecursion just because they _would_ have 
recursed, but didn't _actually_ recurse because they were answered from 
cache; hmmm... now I'm getting tempted to stand up a 9.5 instance so I 
can test for myself).

                                                                         
               - Kevin