[Leaplist] Name Service Cache Daemon (nscd)

[Kevin Korb]

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

Can nscd flush specific entries from its cache?  If so that would be a
benefit.  We ended up writing a custom modification to dnscache that
allows us to purge specific records from the cache instead of dumping the
entire cache.  We even control it from our company IRC channel.

With all of the dns lookups involved in spam filtering for ~11k domains we
do a LOT of DNS queries.  We ended up dedicating a server to dnscache with
2GB of RAM for the cache of lookups.  When we dumped that entire cache it
would actually cause a flood of Nagios alerts as things timed out.

On Thu, 7 Jan 2010 22:18:55 -0500
Andrew Anderson <aander07 at packetmaster.com> wrote:
> 
> On Jan 7, 2010, at 10:21 AM, Kevin Inscoe wrote:
> 
> > I have a constant battle at work about the nscd daemon. I have
> > consistently had problems with it in both Solaris and RHEL. I am being
> > asked (read semi-forced) to institute it again (I am the one of the
> > Linux build masters for the company) in RHEL 4 and 5 . I would be
> > grateful for any hard evidence documentation from any where to either
> > it's benefits or problems in production environments. Personal
> > anecdotes are also welcome. Yes I have STFG.
> 
> It depends on your environments and the services that you are running.
> 
> One case where it helped out tremendously was on high-volume download
> FTP servers that were setup with network-based authentication for admin
> access.  Each and every client connection triggered name service
> lookups, and that lookups traffic was non-trivial.  By enabling nscd,
> the traffic dropped dramatically and response times improved.  Depending
> on the services you offer, and how they are configured, you may or may
> not see similar benefits.
> 
> For example, a web server out of the box probably would not see much
> improvement, unless you 1) set it up to do reverse DNS lookups on
> incoming connections for name-based host access controls, or 2) use a
> network authentication service for user-based access controls.  In those
> setups, nscd may show an improvement;  the higher the volume, of course,
> the more dramatic the improvement.
> 
> The caveat there was to be aware that you were on a nscd enabled host
> and making liberal use of "nscd -i" to flush the proper cache when you
> were getting data that was inconsistent with what you were expecting due
> to a change that just happened and the old data had not expired from the
> cache yet.  This situation is the one that I most commonly hear
> expletives uttered at nscd. :)
> 
> 


- -- 
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
	Kevin Korb			Phone:    (407) 252-6853
	Systems Administrator		Internet:
	FutureQuest, Inc.		Kevin at FutureQuest.net  (work)
	Orlando, Florida		kmk at sanitarium.net (personal)
	Web page:			http://www.sanitarium.net/
	PGP public key available on web site.
~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~'`^`'~*-,._.,-*~
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)

iEYEARECAAYFAktGphUACgkQVKC1jlbQAQetcQCeKrJVWOu7KrvF2X9f4LkpoUPS
QfEAoMrUkQycm2l37bBWW5PO7o8OLMBh
=UQ21
-----END PGP SIGNATURE-----

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.