Need performance hints for large servers

Need performance hints for large servers

Post by ron na » Wed, 15 Mar 1995 07:13:04



Hello, we are running a SS10 model 514 with 512MB of ram with Solaris 2.4.
Current configuration has 9,000 users in the password file and allows up
to 200 connections.  We are not running NIS or NIS+.  What can I do to
improve performance of password file lookups?  95% of the time the system
response is good to very good unless you do something that hits on the
/etc/passwd file like:
        /usr/ucb/ps -aux
Then the 800 or 900 process display at a rate of about 2 per second.
Other commands similarly affected are "ls -l" and "finger".

Any suggestions or help is appreciated!
--
             ,--, | Ron Nash      San Diego State University

   ,;`( )__, )  ~ |  
  //  //   '--;   | Gin-N-Tonic   endurance horse
  '   \     |     | Luv on Fire   trusty trail horse

 
 
 

Need performance hints for large servers

Post by John DiMar » Fri, 17 Mar 1995 10:32:41



>Hello, we are running a SS10 model 514 with 512MB of ram with Solaris 2.4.
>Current configuration has 9,000 users in the password file and allows up
>to 200 connections.  We are not running NIS or NIS+.  What can I do to
>improve performance of password file lookups?  95% of the time the system
>response is good to very good unless you do something that hits on the
>/etc/passwd file like:
>    /usr/ucb/ps -aux
>Then the 800 or 900 process display at a rate of about 2 per second.
>Other commands similarly affected are "ls -l" and "finger".

The problem occurs most often when mapping uids to user names.  The "files"
implementation of getpwuid and friends does a linear search in the password
file.

The easiest way to "solve" the problem is to use NIS, but that brings along
a whole set of new problems.  The right way to solve the problem is to write a
dbm-style backend for the password file.  The name services switch interface is
documented in /usr/include/nss_*, if you want to give it a try.  

Regards,

John
--

Computing Disciplines Facility Systems Manager            Phone: 416-978-1928
University of Toronto                                     Fax:   416-978-1931
http://www.cdf.toronto.edu/personal/jdd/jdd.html

 
 
 

Need performance hints for large servers

Post by Jeff Bonwi » Sat, 18 Mar 1995 17:14:30



> Hello, we are running a SS10 model 514 with 512MB of ram with Solaris 2.4.
> Current configuration has 9,000 users in the password file and allows up
> to 200 connections.  We are not running NIS or NIS+.  What can I do to
> improve performance of password file lookups?  95% of the time the system
> response is good to very good unless you do something that hits on the
> /etc/passwd file like:
>    /usr/ucb/ps -aux
> Then the 800 or 900 process display at a rate of about 2 per second.
> Other commands similarly affected are "ls -l" and "finger".

[ copied from another thread ]

This is addressed in Solaris 2.5 by the nscd (name service cache daemon).
A call to gethostbyname(), getpwent(), etc. turns into a door_call() to
the nscd.  (Doors are a fast local IPC mechanism, also new in 2.5.)
The nscd keeps a cache of various getXbyY() mappings and consults the
underlying name service only on cache misses.  This reduces latency from
tens of milliseconds (under good network conditions) to tens of microseconds
(consistently).  It also improves the effective scalability of the
underlying name service because you just don't stress it as much.

If you're using YP or NIS+ this cuts your network traffic quite a bit.
It's also helpful for local files (e.g. /etc/passwd) because it's much
cheaper to do a simple hash lookup than to parse /etc/nsswitch.conf and
/etc/passwd each time -- especially for large passwd/group/hosts files.

Jeff Bonwick
Solaris Performance

 
 
 

Need performance hints for large servers

Post by Robert Davi » Sun, 19 Mar 1995 03:14:32


I'm cross-posting to comp.security.unix in case something already exists, and
comp.lang.perl, just on the off chance that they can whip it up over the weekend  :)


*
* >Current configuration has 9,000 users in the password file and allows up
* >to 200 connections.  We are not running NIS or NIS+.  What can I do to
* >improve performance of password file lookups?  95% of the time the system

The reason I've not wanted to simply rdist, local files is because of this.
Even with NIS under SunOS 4 I've had to do workrounds, using Net Groups, to
restrict access to some machines, and some grotesque hacks.

For Solaris I've been expecting to have to implement, a special login program,
once the NIS compat is dropped (or I drop NIS).


* The easiest way to "solve" the problem is to use NIS, but that brings along
* a whole set of new problems.  The right way to solve the problem is to write a
* dbm-style backend for the password file.  The name services switch interface is
* documented in /usr/include/nss_*, if you want to give it a try.  

Now that's an idea!

I've been pondering this as local files, NS kit and NIS+ have too many gotcha's.
Would there be any takers for PNR - Portable Name Resolution?

The aim would be quick and dirty hack (to begin with), I see 2 parts to this :

    1) Master format - some management tools,
                     - distribution scheme -> local format flat file, Berkeley DB,
                                  dbm file, NIS maps, whatever
                     - mapping scheme for Bastion hosts, DBs and such like

    2) OS specific implentation
                     - Solaris 2.4 using name service switch.
                     - ULTRIX supports DBM passwd file or local ypservs.
                     - SunOS 4, DBM in /var/yp/`domainname` plus ypserv & securenets?

The OS part, could become unecessary, when Vendors introduce better caching.

Perl5 and the Berkeley DB lib, allow simple creation of lookup caches,
analagous to NIS's <map>.by<key> DBM files, only :

     1)  faster, through a memory cache, but a limited one to avoid swap
     2)  byte independant, makes it very rdist-able
     3)  hash / btrees supported

Some mechanism to distribute a master DB, to allow OS specific format files,
like passwd(5), whoops (ggrrrrr) I meant passwd(4) and shadow(4)).

A daemon to handle password changes would be required, rlogin to a master host
is not acceptable (inconvenient and clear text passwords over net).

Perhaps something better than NIS that's not OS specific already exists?
Did the BSD User DB get any further than it's usage in V8 sendmail?

-- Rob

 
 
 

Need performance hints for large servers

Post by Bart Smaalde » Sun, 19 Mar 1995 03:49:54


For what it's worth, this is fixed in 2.5 with the nscd, a
multi-threaded cache daemon that handles get{group,host,passwd} and
netdir_by* lookups.  Time for typical getxbyy calls are typically 250
usecs if the data is in the cache, and processes no longer need to open
/etc/nsswitch.conf, dlopen libs, etc; the daemon does that once at
startup.

For a short term bandaid, you can place frequent users first in the
passwd file, but John DiMarco is right that running NIS is probably the
easiest fix for 2.4 systems.  Note that 4.x had the same problems; when
I worked in Sun manufacturing (before we switched to NIS) we would
routinely sort the hosts (20K entries) file every night to place local
machines we needed to talk to in the first few K of the file.

- Bart Smaalders        OS Performance          SunSoft



>>Hello, we are running a SS10 model 514 with 512MB of ram with Solaris 2.4.
>>Current configuration has 9,000 users in the password file and allows up
>>to 200 connections.  We are not running NIS or NIS+.  What can I do to
>>improve performance of password file lookups?  95% of the time the system
>>response is good to very good unless you do something that hits on the
>>/etc/passwd file like:
>>        /usr/ucb/ps -aux
>>Then the 800 or 900 process display at a rate of about 2 per second.
>>Other commands similarly affected are "ls -l" and "finger".

>The problem occurs most often when mapping uids to user names.  The "files"
>implementation of getpwuid and friends does a linear search in the password
>file.

>The easiest way to "solve" the problem is to use NIS, but that brings along
>a whole set of new problems.  The right way to solve the problem is to write a
>dbm-style backend for the password file.  The name services switch interface is
>documented in /usr/include/nss_*, if you want to give it a try.  

>Regards,

>John
>--

>Computing Disciplines Facility Systems Manager            Phone: 416-978-1928
>University of Toronto                                     Fax:   416-978-1931
>http://www.cdf.toronto.edu/personal/jdd/jdd.html

 
 
 

Need performance hints for large servers

Post by Doug Hugh » Tue, 28 Mar 1995 23:49:08




> > Hello, we are running a SS10 model 514 with 512MB of ram with Solaris 2.4.
> > Current configuration has 9,000 users in the password file and allows up
> > to 200 connections.  We are not running NIS or NIS+.  What can I do to
> > improve performance of password file lookups?  95% of the time the system
> > response is good to very good unless you do something that hits on the
> > /etc/passwd file like:
> >       /usr/ucb/ps -aux
> > Then the 800 or 900 process display at a rate of about 2 per second.
> > Other commands similarly affected are "ls -l" and "finger".

> [ copied from another thread ]

> This is addressed in Solaris 2.5 by the nscd (name service cache daemon).
> A call to gethostbyname(), getpwent(), etc. turns into a door_call() to
> the nscd.  (Doors are a fast local IPC mechanism, also new in 2.5.)
> The nscd keeps a cache of various getXbyY() mappings and consults the
> underlying name service only on cache misses.  This reduces latency from
> tens of milliseconds (under good network conditions) to tens of microseconds
> (consistently).  It also improves the effective scalability of the
> underlying name service because you just don't stress it as much.

> If you're using YP or NIS+ this cuts your network traffic quite a bit.
> It's also helpful for local files (e.g. /etc/passwd) because it's much
> cheaper to do a simple hash lookup than to parse /etc/nsswitch.conf and
> /etc/passwd each time -- especially for large passwd/group/hosts files.

> Jeff Bonwick
> Solaris Performance

Could you post a good summary of what exactly a door is and does for you
and how it can be used? Sounds a bit like BSD4.4 portals to me... Is
that what it's based upon? (that would be really cool... :) )

--
____________________________________________________________________________
Doug Hughes                                     Engineering Network Services
System/Net Admin                                Auburn University

                "Real programmers use cat > file.as"

 
 
 

1. Portable Name Resolution (was Need performance hints for large servers)

I'm cross-posting to comp.security.unix in case something already exists, and
comp.lang.perl, just on the off chance that they can whip it up over the weekend  :)


*
* >Current configuration has 9,000 users in the password file and allows up
* >to 200 connections.  We are not running NIS or NIS+.  What can I do to
* >improve performance of password file lookups?  95% of the time the system

The reason I've not wanted to simply rdist, local files is because of this.
Even with NIS under SunOS 4 I've had to do workrounds, using Net Groups, to
restrict access to some machines, and some grotesque hacks.

For Solaris I've been expecting to have to implement, a special login program,
once the NIS compat is dropped (or I drop NIS).


* The easiest way to "solve" the problem is to use NIS, but that brings along
* a whole set of new problems.  The right way to solve the problem is to write a
* dbm-style backend for the password file.  The name services switch interface is
* documented in /usr/include/nss_*, if you want to give it a try.  

Now that's an idea!

I've been pondering this as local files, NS kit and NIS+ have too many gotcha's.
Would there be any takers for PNR - Portable Name Resolution?

The aim would be quick and dirty hack (to begin with), I see 2 parts to this :

    1) Master format - some management tools,
                     - distribution scheme -> local format flat file, Berkeley DB,
                                  dbm file, NIS maps, whatever
                     - mapping scheme for Bastion hosts, DBs and such like

    2) OS specific implentation
                     - Solaris 2.4 using name service switch.
                     - ULTRIX supports DBM passwd file or local ypservs.
                     - SunOS 4, DBM in /var/yp/`domainname` plus ypserv & securenets?

The OS part, could become unecessary, when Vendors introduce better caching.

Perl5 and the Berkeley DB lib, allow simple creation of lookup caches,
analagous to NIS's <map>.by<key> DBM files, only :

     1)  faster, through a memory cache, but a limited one to avoid swap
     2)  byte independant, makes it very rdist-able
     3)  hash / btrees supported

Some mechanism to distribute a master DB, to allow OS specific format files,
like passwd(5), whoops (ggrrrrr) I meant passwd(4) and shadow(4)).

A daemon to handle password changes would be required, rlogin to a master host
is not acceptable (inconvenient and clear text passwords over net).

Perhaps something better than NIS that's not OS specific already exists?
Did the BSD User DB get any further than it's usage in V8 sendmail?

-- Rob

2. Creating tcsh or csh alias containing both single-quotes and dollar

3. Need some hints for DLing large files in C...

4. IBM drive FastStart install

5. Need UNIX/Informix Performance Hints

6. I want LESS color..:)

7. Performance configuration hint for Apache 1.1b3.

8. Squid and Apache Problems

9. performance hints for X on slow systems

10. Need suggestions for high performance streaming server

11. Need help on database server performance problem

12. High performance server - Hardware recommendation needed

13. porting from SysVr3 to SysVr4 - hints and tips needed