Caching only servers

[Georgeson, Evan [NCSUS Non J&J]]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin,

	Sounds good, will do. The very last question I have on this is...the
options max-cache ttl and max-ncache ttl are both overwritten by the
zone file values. Does adjusting these really have a noticable
impact? Note: my previous max-ncache ttl value was 1 day, I've since
changed that to 1 hour. Would the max-cache value of 2 hrs be
appropriate in your opinion (absolute last question...unless your
response inspires me.)? Thanks again for your advice.

- -----Original Message-----
From: Kevin Darcy [mailto:kcd at daimlerchrysler.com] 
Sent: Tuesday, July 16, 2002 8:49 PM
To: bind-users at isc.org
Subject: Re: Caching only servers



If you're that short of memory, then it's going to be a narrow margin
between being too aggressive and keeping too much data resident, on
the one hand, plus hitting up the CPU all the time to do cleaning,
versus, on the other hand, not cleaning aggressively enough and
having your virtual memory fill up with unused or little-used cache.
You could play with it and try to hit the "sweet spot" between those
2 extremes. You could also try playing with max-cache-ttl (the evil
twin of max-ncache-ttl), which will give your nameserver more
cleaning opportunities, at the expense, of course, of increasing
query latency times for data that were cleaned out of the cache
prematurely.


- - Kevin

"Georgeson, Evan [NCSUS Non J&J]" wrote:

>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Thanks Kevin...I've since uncovered these wonderful little tidbits.
>  See, we use QIP and in so doing we have some systems with ISC BIND
>  with the majority using Lucent-BIND. Now, 2 weeks ago our
> deployment  dept removed 9.1.3 and went to Lucent-BIND. These
> serving problems  just started last week so I suspect
> this...considering our caching  servers only have, don't laugh, 256
> MB of RAM (my laptop has 512!) I  believe the Lucent BIND added
> some memory overhead that pushed an  already overtaxed system(s)
> over the edge. Today we've since reverted  to 9.1.3. We will be
> adding more memory, of course, but do you think  that there is any
> reason to re-visit my cleaning-interval? Do you have  a suggestion
> on a new value? Also, is there a Lucent-BIND support  group similar
> to this? Thank you again for your time and advice.
>
> Evan
>
> - -----Original Message-----
> From: Kevin Darcy [mailto:kcd at daimlerchrysler.com]
> Sent: Tuesday, July 16, 2002 5:19 PM
> To: BIND Users (bind-users at isc.org)
> Subject: Re: Caching only servers
>
> "Georgeson, Evan [NCSUS Non J&J]" wrote:
>
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi,
> >
> >         I'm suffering some bizarre symptoms on my two cache
> > servers.   For some reason, they stop servicing internal requests
> > and then restart after a few minutes. Could there be a load
> > issue?
>
> Yes :-)
>
> > I'm going to give
> > you a list of the named.conf options can I get someone to check
> > them   for validity and confirm correct or no?? Thank you very
> > much if you   can help or advise.
>
> Your cleaning-interval is set to 4 minutes. That seems a little
> rabid.  Did you increase the frequency to try to keep your memory
> usage down?  If you have sufficient memory, I'd relax the cleaning
> interval. By  touching your memory pages this frequently, you may
> be forcing them to  be resident more often and actually *hurting*
> your memory situation. 
>
> > Also, is it logged when nslookup queries return nxdomain or 
> > servfail,  e.g., queries.log??
>
> No, I do not believe this is available in the query log.
>
> NXDOMAIN is a fairly routine reponse code; clients ask for 
> non-existent names all of the time (especially when they are 
> configured with searchlists, grrrrr....)
>
> SERVFAIL is not so common, but in general, whatever is causing the 
> SERVFAIL condition is being logged by your nameserver in some other
>  way. Unfortunately, there are many different things which can give
>  rise to a SERVFAIL -- it's kind of a catch-all category.
>
> You can try turning up the logging for various categories and/or 
> turning on debugging, if you want more information on these 
> conditions, but be aware that this will drive up your resource 
> consumption, which you may not want to do at this time.
>
> - - Kevin
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP 7.1
>
> iQA/AwUBPTSirmcmEMqSL6AwEQLoDwCeKrL/8OI/ZhooWvgKMU4judIoUmcAoPRq
> AeYE+efm9Mkvg55imC9kCJSe
> =U/mb
> -----END PGP SIGNATURE-----


-----BEGIN PGP SIGNATURE-----
Version: PGP 7.1

iQA/AwUBPTTCzWcmEMqSL6AwEQKjKACfYxIGviCNpWD0dkZ9x/G3QUa/dnwAn3qF
uFTTu4ZL5xUSENN8E5Dz7STN
=kexJ
-----END PGP SIGNATURE-----