Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My server seized up. It was virtually unusable. This seemed like a likely culprit:

root      1037  0.0 92.6 1455696 958368 ?      Ssl   2012   3:57 /usr/sbin/nscd

That's 92% RAM. I killed it to get my server operational again.

Given that I have now killed the process, what post-mortem diagnostics can I do to see what the cause was? top occasionally showed high wa values, which might suggest there might be something up with a file or network socket it was trying to read? Any suggestions?

share|improve this question
Which OS and/or distro. Any relevant log entries ? – Iain Jan 7 '13 at 11:11
Debian GNU/Linux 6.0 . I'm not sure which logs to look in. – Joe Jan 7 '13 at 11:16
Start with /var/log/messages, /var/log/syslog then /var/log/* ingeneral – Iain Jan 7 '13 at 11:23
Bug report - You can restart nscd daily, or more often, if needed. – David Schwartz Jan 7 '13 at 11:28
David, that seems like an answer, not a comment. I'd certainly upvote it, if you wrote it up as one, and included some of the actual text as well as a link. – MadHatter Jan 7 '13 at 12:12
up vote 4 down vote accepted

It's because it's full of memory leaks :)

The common approach is to restart the service son some regular interval or at a specified threshold (memory utilization). I usually use the Monit utility to do this (example), but I believe nscd has a built-in provision for this as well in its configuration file.

share|improve this answer
Yeah seems to be the case! Thanks. – Joe Jan 7 '13 at 15:02

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.