Performance penalty from NOT running nscd?
Pat Zurek
I heard somewhere that because nscd does weird stuff to the filesystem,
not running it incurs a performance penalty and that nscd should be left
running, but disabled through nscd.conf. I tried google, but found
nothing mentioning a performance hit from not running nscd.
Thanks!
Pat Zurek
pzu...@uillinois.edu
James Carlson
> Currently, the nscd daemon is not running on any of our servers.
Why?
> Recently,
> I heard somewhere that because nscd does weird stuff to the filesystem,
Really? Any references?
> not running it incurs a performance penalty and that nscd should be left
> running, but disabled through nscd.conf. I tried google, but found
> nothing mentioning a performance hit from not running nscd.
Nscd is the "name service cache daemon." If you don't enable it, then
most resolution that goes through nsswitch.conf (e.g., host name to IP
address translation and UID to user name translation) will hit the
underlying services. This can be quite slow. When nscd is enabled,
the library makes libdoor(3lib) calls to the daemon to look up cached
answers, and it's a lot faster.
In general, you should just run it the way the system is delivered,
with nscd enabled. See nscd(1M) and nscd.conf(4) for details.
--
James Carlson, Solaris Networking <james.d...@east.sun.com>
Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677
Richard McDougall
Not running NSCD will cause repeat lookups (those that would have hit in the
name service cache) to take in the order of milliseconds, rather than a few tens
of microseconds (or however long it takes to go to the nameserver for _every_
getxbyy().
I've never heard of nscd doing anything "weird" to the filesystem, and would
very much like to know what the issue was. Are you able to followup with some
more information on the file system issue?
Thanks,
Richard
Matt Atterbury
James Carlson <james.d...@sun.com> writes:
> "Pat Zurek" <pzu...@uiuc.edu> writes:
> > Currently, the nscd daemon is not running on any of our servers.
>
> Why?
One reason not to run it is that it "leaks" memory like a sieve, or at
least does nothing to stop itself from growing indefinitely. 80Mb on
one Solaris 8 box here, and I repeatedly have to ask sysadmins to
restart it on various machines due to its ridiculous [virtual] size.
m.
Toomas Soome
have you considered to check for patches?:) also, with big system, the
cache can be big as well. whats nscd -g telling?
toomas
--
Take heart amid the deepening gloom that your dog is finally getting
enough cheese
-- National Lampoon, "Deteriorata"
Martin Paul
> In general, you should just run it the way the system is delivered,
> with nscd enabled. See nscd(1M) and nscd.conf(4) for details.
I'd recommend setting all keep-hot-count's to 0. This was the only
thing that made my client workstations emit network traffic on their
own if they are running with nobody logged in. A failing NIS server
(or the network connection to it) made all NIS clients scream about
the missing NIS binding - pretty useless.
Otherwise I'm running nscd on all my machines since it appeared
in 2.6 (?) without any issues.
mp.
--
Martin Paul | Systems Administrator
Institute for Software Science | mar...@par.univie.ac.at
University of Vienna, Austria | http://www.par.univie.ac.at/
mmmmm
you are lucky :)
320 MB here !
"Matt Atterbury" <ma...@nospam.com> a écrit dans le message de news:
7vfyzo...@lyra.i-did-not-set--mail-host-address--so-shoot-me...
Rich Teer
> 80MB ?
> you are lucky :)
> 320 MB here !
320 MB? You were lucky! When I were a lad, we had nscd process
sizes exceeding 20 GB, before the machine had even booted. Our
systems only had 4 MB of RAM and we used 0.25" tape on a narrow
5 MB/sec SCSI-1 bus as our swap device.
And you try tellin' the sysadmins of today that, and they won't
believe ya!
--
Rich Teer
President,
Rite Online Inc.
Voice: +1 (250) 979-1638
URL: http://www.rite-online.net
Pat Zurek
> "Pat Zurek" <pzu...@uiuc.edu> writes:
>> Currently, the nscd daemon is not running on any of our servers.
>
> Why?
James, thank you for replying. I do not know the particular details of
why it is not running (I am just a student worker in the university) but I
can speculate why.
"Name Service Cache Daemon implements a cache for name service requests in
order to speed up name resolution. Unfortunately, it is not a particularly
secure piece of software. In addition, caching might not be the desired
functionality in all environments. Therefore, if you can tolerate a minor
degradation in name service resolution performance (which won't even be
noticeable on high-end systems) you should disable nscd..." Edgar
Danielyan "Solaris 8 Security."
The servers run Oracle databases in 52 and 8 CPU configurations,
communication is primarily restricted to other servers within the subnet.
Further, the user load rarely exceeds 4 concurrent users.
>> Recently,
>> I heard somewhere that because nscd does weird stuff to the filesystem,
>
> Really? Any references?
I realize the details were sketchy, but I couldn't figure out how to word
it any better. My supervisor mentioned it to me, unfortunately, he
couldn't remember from where - or any relevent details. Being the
management type, he's almost as far removed above the Sun equipment (in
terms of technical knowledge) as I am below in my ignorance.
What I meant to ask is, are there any situations in which it is desirable
to be running nscd functionally disabled (through nscd.conf such as
below) instead of being disabled entirely.
enable-cache hosts no
enable-cache ipnodes no
enable-cache passwd no
enable-cache groups no
Thanks, Pat Zurek
pzu...@uiuc.edu
Scott Howard
> One reason not to run it is that it "leaks" memory like a sieve, or at
> least does nothing to stop itself from growing indefinitely. 80Mb on
> one Solaris 8 box here, and I repeatedly have to ask sysadmins to
> restart it on various machines due to its ridiculous [virtual] size.
Sounds like
4159699 nscd's size grows - TTL values not implemented
Fixed many moons ago for at least Solaris 2.6 and later.
Scott
Matt Atterbury
Then it's clearly not that problem since this is on Solaris 8 (as said
above).
As for patches, no, I haven't looked since it's easier for me to
restart nscd than try to find and apply patches. The Solaris 8 version
is also reasonably current ... above a year old now IIRC.
nscd -g displays lots of meaningless info. I cannot see the point of a
previous poster asking what it says since it seems to say nothing
about memory usage.
# nscd -g
nscd configuration:
0 server debug level
"" is server log file
passwd cache:
Yes cache is enabled
115677 cache hits on positive entries
22 cache hits on negative entries
1869 cache misses on positive entries
157 cache misses on negative entries
98% cache hit rate
0 queries deferred
15 total entries
211 suggested size
600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
group cache:
Yes cache is enabled
8214 cache hits on positive entries
0 cache hits on negative entries
195 cache misses on positive entries
15 cache misses on negative entries
97% cache hit rate
0 queries deferred
12 total entries
211 suggested size
3600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
hosts cache:
Yes cache is enabled
400471 cache hits on positive entries
247 cache hits on negative entries
3591 cache misses on positive entries
232 cache misses on negative entries
99% cache hit rate
0 queries deferred
86 total entries
211 suggested size
3600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
ipnodes cache:
Yes cache is enabled
51 cache hits on positive entries
8410 cache hits on negative entries
1 cache misses on positive entries
2368 cache misses on negative entries
78% cache hit rate
0 queries deferred
37 total entries
211 suggested size
3600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
exec_attr cache:
Yes cache is enabled
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 queries deferred
0 total entries
211 suggested size
3600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
prof_attr cache:
Yes cache is enabled
0 cache hits on positive entries
0 cache hits on negative entries
0 cache misses on positive entries
0 cache misses on negative entries
0% cache hit rate
0 queries deferred
0 total entries
211 suggested size
3600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
user_attr cache:
Yes cache is enabled
1385 cache hits on positive entries
576 cache hits on negative entries
1 cache misses on positive entries
422 cache misses on negative entries
82% cache hit rate
0 queries deferred
13 total entries
211 suggested size
3600 seconds time to live for positive entries
5 seconds time to live for negative entries
20 most active entries to be kept valid
Yes check /etc/{passwd, group, hosts, inet/ipnodes} file for changes
No use possibly stale data rather than waiting for refresh
#
Martin Paul
> Scott Howard <sc...@hunterlink.net.au> writes:
>> Sounds like
>> 4159699 nscd's size grows - TTL values not implemented
>>
>> Fixed many moons ago for at least Solaris 2.6 and later.
>
> Then it's clearly not that problem since this is on Solaris 8 (as said
> above).
There is patch for Solaris 8, too, fixing the same bug - 110710-01.
Might be preinstalled in later Solaris 8 releases.
> As for patches, no, I haven't looked since it's easier for me to
> restart nscd than try to find and apply patches.
You really should change this attitude.
The bug README lists a workaround too - removing "xfn" from
/etc/nsswitch.conf. Don't know if this applies to (more recent
versions of) Solaris 8.
> The Solaris 8 version is also reasonably current ...
> above a year old now IIRC.
If you haven't applied any patches for one year, it's not reasonably
current anymore.
Tony Walton
> Matt Atterbury <ma...@nospam.com> wrote:
>
>>Scott Howard <sc...@hunterlink.net.au> writes:
>>
>>>Sounds like
>>>4159699 nscd's size grows - TTL values not implemented
>>>
>>>Fixed many moons ago for at least Solaris 2.6 and later.
>>
>> Then it's clearly not that problem since this is on Solaris 8 (as said
>> above).
>
>
> There is patch for Solaris 8, too, fixing the same bug - 110710-01.
> Might be preinstalled in later Solaris 8 releases.
Fixed in Solaris 8 U4 (April 2001).
--
Tony
Matt Atterbury
[snip]
> > As for patches, no, I haven't looked since it's easier for me to
> > restart nscd than try to find and apply patches.
>
> You really should change this attitude.
Why? nscd can be restarted with affecting any running processes.
patches cannot be applied without rebooting (in my experience). To me
this is a no brainer - production machines don't get rebooted unless
they *really* have to and nscd doesn't come close.
> The bug README lists a workaround too - removing "xfn" from
> /etc/nsswitch.conf. Don't know if this applies to (more recent
> versions of) Solaris 8.
>
> > The Solaris 8 version is also reasonably current ...
> > above a year old now IIRC.
>
> If you haven't applied any patches for one year, it's not reasonably
> current anymore.
Another poster said this bug was fixed in the 04/01 release so my
version should have it (that's nearly 2 years ago). I consider a year
old as *reasonably* current for a production machine.
m.
Martin Paul
> Why? nscd can be restarted with affecting any running processes.
> patches cannot be applied without rebooting (in my experience).
Most patches can be be installed without rebooting. The nscd patch
e.g. only brings in one new file - /usr/sbin/nscd. It's enough to
stop/start it after patch installation.
> Another poster said this bug was fixed in the 04/01 release so my
> version should have it (that's nearly 2 years ago). I consider a year
> old as *reasonably* current for a production machine.
If you think so .. it's not too useful to post here about bugs you
experience which might have been fixed long ago without you noticing
because you don't install patches.
Tony Walton
>
>
> Another poster said this bug was fixed in the 04/01 release so my
> version should have it (that's nearly 2 years ago).
That'd be me, that would. Are you saying you're running a version of
Solaris 8 which is 04/01 or later (cat /etc/release to find out) and are
still seeing nscd growing to a humungous size? If so this may be a bug
(a different one to the one fixed in 8-04/01 and in patch 110710-01)
that needs fixing.
--
Tony
ultra...@hotmail.com
>I've never heard of nscd doing anything "weird" to the filesystem, and would
>very much like to know what the issue was. Are you able to followup with some
>more information on the file system issue?
he may think that door files are wierd.
Matt Atterbury
> Matt Atterbury <ma...@nospam.com> wrote:
[snip]
> > Another poster said this bug was fixed in the 04/01 release so my
> > version should have it (that's nearly 2 years ago). I consider a year
> > old as *reasonably* current for a production machine.
>
> If you think so .. it's not too useful to post here about bugs you
> experience which might have been fixed long ago without you noticing
> because you don't install patches.
I am not the OP - I merely followed up with a possible reason for not
running nscd.
m.
Matt Atterbury
[snip]
> That'd be me, that would. Are you saying you're running a version of
> Solaris 8 which is 04/01 or later (cat /etc/release to find out) and are
> still seeing nscd growing to a humungous size? If so this may be a bug
> (a different one to the one fixed in 8-04/01 and in patch 110710-01)
> that needs fixing.
My apologies Tony ... the machine was installed about a year ago and I
had assumed that the installer used our latest CDs (10/01), but
apparently its 10/00 [thanks for the /etc/release info] :-( Time to
turn those old CDs into drink coasters methinks!
On the other hand, one of the production machines has 07/01 and its
nscd is 62Mb:
$ cat /etc/release
Solaris 8 7/01 s28s_u5wos_08 SPARC
Copyright 2001 Sun Microsystems, Inc. All Rights Reserved.
Assembled 06 June 2001
$ uname -a
SunOS xxxxxxxx 5.8 Generic_108528-09 sun4u sparc SUNW,Ultra-1
Thanks for the info on the patch - I will take Martin's advice and
look at getting it installed.
m.