Recommended setup with large cache memory

[Attila Nagy]

JINMEI Tatuya / 神明達哉 wrote:
> (As already mentioned in this thread) Using
> ISC_MEM_USE_INTERNAL_MALLOC should definitely help.  It doesn't harm
> particularly for a uniprocessor machine, so I suggest that you try it
> if not yet.
I have already defined it. With this, bind finishes its cleaning job 
much sooner and it seems that during the sweeping, it stays responsive, 
unlike previously.
So it definiately helps.

> You may also want to decrease a hard-coded parameter that controls the
> number of cache entries examined for cleaning at once.  The parameter
> is defined at line 48 of bind-9.3.1/lib/dns/cache.c
> #define DNS_CACHE_CLEANERINCREMENT	1000	/* Number of nodes. */
After discussing various aspects of bind with Brad, I took a quick look 
on the source and found this. Currently, I am waiting for the load to 
increase and log every timeouts. If internal malloc doesn't help, I will 
try this.

> I hear that dropped queries with the default setting during the
> periodic cleaning went away by decreasing this to 200 for an ISP
> caching server.  Note that changing this value does not decrease the
> cleaning load, so the server will still eat CPU during the cleaning
> period.  Also, decreasing this parameter will probably make the
> cleaning period longer.
I don't really care how long the sweeping runs, if the server can do its 
job. :)

> Setting cleaning-interval to 0 and letting max-cache-size do all the
> work for managing the cache size may also help in some environments as
> you indicated.  But I suspect it cannot be a general solution because
For me, with a max-cache-size of 1200MB yielded about 1.6-1.8GB of 
process size with 0 cleaning-interval, but it has been growing much 
slower after the 1 GB limit and the growth was linear...

> the internal code logic is (almost) the same for periodical cleaning
> and cleaning on over-memory.  For example, DNS_CACHE_CLEANERINCREMENT
> equally applies to both, so if the period cleaning prevents your
> server from answering some queries the same thing should happen in
> cleaning due to over-memory.
Thanks for the information.

-- 
Attila Nagy                                   e-mail: Attila.Nagy at fsn.hu
Free Software Network (FSN.HU)           phone @work: +361 371 3536
ISOs: http://www.fsn.hu/?f=download            cell.: +3630 306 6758