Here is a summary that I promised about how to deal with the
bloated nscd. It was a problem on all machines in our web
server array. As time goes by, the footprint of nscd grew
without bounds and I used to reboot these machines once a
month or so to get rid of the bloated nscd.
First of all, I would like to thank the following Sun managers:
Marks, Evan R <markser@aetna.com>
Neal S. Pressman <nsp83273@cae091.ed.ray.com>
Casper Dik <casper@holland.Sun.COM>
Aggelos P. Varvitsiotis <avarvit@cc.ece.ntua.gr>
Matt Bottrell <mattb@deakin.edu.au>
Mark P. Beckman <beckman@bofh.fleet.capital.ge.com>
Tony Jago <tony@fit.qut.edu.au>
Stephen Harris <sweh@mpn.com>
Next, what I have taken so far (cut and pasted from a /etc/nscd.conf):
[deleted]
# The hosts cache is disabled as an attempt to reduce the RAM
# consumption of the nscd.
#
# C. Fang 01/01/97
#
# logfile /var/tmp/nscd.log
enable-cache hosts no
[deleted]
As a side, this is what it always has been for hosts in our web servers's
/etc/nsswitch.conf.
hosts: files dns
So far, after one day or so, I haven't seen any significant growing
of nscd's footprint on any of our machines. I decided not to kill
the daemon as suggested by some managers. As indicated above, we
do use DNS for host name resolution here (the file is just a backup
thing), as explained below by Casper Dik, in this case nscd grows
without bounds. Thus the enable-cache hosts is set to no as
recommended by Casper Dik and Tony Jago. Mark P. Beckman's suggestion
to use the -g option is also helpful. I should have used it. I will
also try the pmat utility too.
Thanks again to all!
Chin Fang
fangchin@jessica.stanford.edu
============================================================================
Comments from all helpful Sun managers listed above are attached below:
o From Marks, Evan R
just kill it. I find not running nscd does not hurt anything...
Evan R. Marks
o From Neal S. Pressman
just a thought but have you tried a kill -1 on the pid of nscd to restart it?
o From Casper Dik
First try "pmap <pid of nscd>"
Secondly, I think thre are cases where nscd grows without bound and
that typicallyhappens when you use "dns" for hosts. Is that the case
att your site? If so, you might want to disable nscd for hosts
(see nscd.conf(4))
o From Aggelos P. Varvitsiotis
I 'd say there's no need to reboot your machine just for the sake
of nscd. nscd is used on SOlaris to cache network addressing info,
such as NIS+/NIS/DNS data and the like. In an environment like
yours, it may be natural for nscd to eat up all memory, depending
on its configuration parameters. Maybe adjusting nscd.conf parameters
will solve your problem. In any case, you can safely kill and restart
nscd without rebooting.
o From Matt Bottrell
We find that we DON'T run the nscd (Name Server Cache Daemon) on our machines.
We too found bad performance when doing so....
It caches any DNS request, though we found that there was no benefit in doing
so, as most hosts are contacted within Deakin, and after a few months work
the nscd was bringing our boxes down to a grinding halt! :(
Do you need to run nscd?
o From Mark P. Beckman
What does /usr/sbin/nscd -g show? Any hints? What about ttl's in the
cache?
Also, have you tried doing an /etc/init.d/nscd stop, /etc/init.d/nscd
start instead of rebooting the entire box? Might want to try that, if all
else fails, and see if it works. If it does, toss them into a script and
have cron run it weekly or monthly.
o From Tony Jago
Problem is probably to do with host name cacheing. Run a nameserver on
your machine (in.named) and set your /etc/resolv.conf file to point to
the local host (nameserver 127.0.0.1). Make sure you have "dns" in your
"hosts" line of /etc/nsswitch.conf and then uncomment the line
"enable-cache hosts no" to switch off hosts cacheing.
>From Stephen Harris
I **THINK** it's safe to kill and stop this daemon from working at bootup.
It's just a cache manager for various name services, so removing it will
still let the system work, it just won't have this additional cache
service.
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:42 CDT