Recommended setup with large cache memory
Attila Nagy
bra at fsn.hu
Sun Sep 11 17:21:55 UTC 2005
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
More information about the bind-users
mailing list