tuning nscd on RHEL 5.x

[Tim Mooney]

All-

I'm looking for some advice on using and tuning nscd on RHEL 5.2.

We have several IMAP mail servers running RHEL 5.2, each with somewhere
between 3000 and 7000 /etc/passwd entries.

On a busy mail system, there are a few processes (sendmail, procmail,
the imapd processes, et. al.) that will be making getpwnam() and other
calls frequently, so nscd caching seems like it could be a big win.
Our customers can only access the IMAP systems via IMAP.

Using

 	nscd -g

after the systems have been up for a while, the default hit rates for
passwd, group, and hosts is pretty low -- generally less than 10% for
passwd and even less (usually 0%) for group and hosts.

This is mainly because the default (prime) "suggested size" parameter from
/etc/nscd.conf is 211, much too small for a box with this many entries in
/etc/passwd.  I increased it to 1987 (the year I graduated from high
school...) and restarted nscd on one of the boxes, and that's helped the
cache hit rate for the passwd category (it sometimes makes it into the 40%
range), but hasn't done much for group or hosts.

I'm now left with a few questions and observations:

- what tuning have others done to improve the cache hit rates with nscd?
   - in particular, beyond increasing the suggested size, have you
     increased the durations that positive or negative hits are cached?

- on the one system where I increased the suggested size, I've now
   had nscd apparently die on a couple different occassions.  Since nscd
   can't dump core (it can't write to /, its CWD), I don't have any core
   files to show for it.

   Anyone else that's tuned nscd having it exit periodically?

- I've seen recommendations to not even bother with caching the hosts, and
   to just run caching nameservers instead (which we do elsewhere).  Anyone
   care to comment on that?

- we run a nightly script on our IMAP boxes to purge email older than
   30 days in each person's "Spam-Quarantine" folders.  The script uses
   sudo to switch to the user and then run the command to prune old email:

 	sudo -H -u ${THEUSER} /usr/local/sbin/mailutil \
 	prune ${POTENTIAL} \
 	"before ${DATE_THIRTY_DAYS_AGO}" 1> /dev/null

   A few times a week, that cron job outputs a message of the form

     sudo: no passwd entry for joeuser!

   even though joeuser has a passwd file entry.

   I'm suspicious this is nscd screwing up and returning something like
   ENOENT in certain rare conditions, even though the user most certainly
   does exist in /etc/passwd.

   Anyone seen this behavior?

Thanks,

Tim
-- 
Tim Mooney                                             Tim.Mooney at ndsu.edu
Enterprise Computing & Infrastructure                  701-231-1076 (Voice)
Room 242-J6, IACC Building                             701-231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164