Managing NFS and NIS, 2nd Edition - Mike Eisler [276]
Many operating systems use the nonstandard notion of privileged port numbers, which says that only the superuser can create network endpoints bound to a port less than 1024. Many NFS client implementations will bind to ports less than 1024, and many NFS server implementations will refuse NFS accesses if the port is greater than or equal to 1024.
By default, Solaris NFS servers do not care if the client's source port is less than 1024. This is because the security benefits are minimal (given that it is trivial to bind to ports less than 1024 on many non-Unix operating systems).
If you set this parameter to 1 to enable NFS port checking, you may find that some NFS clients cannot access your server.
svc_idle_timeout
This parameter sets the number of milliseconds the NFS server will let a connection go idle before closing it.
This parameter applies to NFS/TCP connections and is set in the Solaris kernel RPC module called rpcmod.
Normally this parameter should be a minute beyond the highest client-side idle timeout among all the clients that connect to your server. Otherwise, you may observe clients sending requests simultaneous with the server tearing down connections. This will result in an unnecessary sequence of connection teardown, followed immediately by connection setup.
nservers
This is an integer argument to the nfsd command. It defines the number of NFS server threads or processes that will be available to service NFS requests.
On some non-Solaris implementations, setting nservers too high can result in bad performance due to three effects:
The number of server threads or processes is allocated up front, taking up lots of precious kernel memory that might not be needed if the server load is minimal. This is not a problem on Solaris since threads are allocated on demand and released when demand ebbs.
The thundering herd problem exists, which results when there are lots of threads, and every time a request arrives, all the idle threads, instead of just one idle thread, are dispatched. If the load is moderate, many CPU cycles can be wasted, as the majority of the threads wake up, find there is nothing to do, and then go back to sleep. This is not a problem under Solaris because only one thread at a time is dispatched when a request arrives.
The Robinson Factor[1] is the final effect. Consider the situation when there are threads doing NFS work, but some are idle. By the time an idle thread is dispatched, an active thread has picked up the request, thus wasting a dispatch of the idle thread. This is not a problem with Solaris.
[1] The Robinson Factor is named after David Robinson, the engineer at Sun Microsystems who observed the issue in Sun's NFS server, and fixed it.
About the Authors
Mike Eisler graduated from the University of Central Florida with a master's degree in computer science in 1985. His first exposure to NFS and NIS came while working for Lachman Associates, Inc., where he was responsible for porting NFS and NIS to System V platforms. He later joined Sun Microsystems, Inc., responsible for projects such as NFS server performance, NFS/TCP, WebNFS, NFS secured with Kerberos V5, NFS Version 4, and JavaCard security. Mike has authored or coauthored several Request For Comments documents for the Internet Engineering Task Force, relating to NFS and security. He is currently a Technical Director at Network Appliance, Inc.
Ricardo Labiaga is a staff engineer at Sun Microsystems, Inc., where he concentrates on networking and wireless technologies. Ricardo spent 8 years in the Solaris NFS group at Sun, where he worked on a variety of development projects with a primary focus on automounting and the NFS server. Ricardo is responsible for implementing significant functionality and performance enhancements to the automounter, as well as leading the NFS Server Logging design team. He holds a master of science degree in computer engineering from The University of Texas at El Paso.
Hal Stern is