UNIX System Administration Handbook - Evi Nemeth [297]
In the past, the maximum number of nfsds was closely tied to the number of process contexts supported by your computer’s CPU chip. These days many implementations share a single context among all copies of nfsd, so that number is no longer a reliable guide. A more reasonable metric is the number of hard disks being served; when NFS activity is heavy, disk bandwidth will be the limiting factor in the NFS pipeline. There’s no reason to run more than a few nfsds per spindle.
Generally speaking, 4 nfsds is adequate for a server that is used infrequently and is few enough that performance problems can’t really arise. On a production server, somewhere between 12 and 20 is a good number. If you notice the load average (as reported by uptime) rising as you add nfsds, you’ve gone too far; back off a bit from that threshold.
On a loaded NFS server with a lot of UDP clients, UDP sockets can overflow if requests arrive while all nfsd “piers” are already in use. You can monitor the number of overflows with netstat -s. Add more nfsds until UDP socket overflows drop to zero. Overflows indicate a severe undersupply of server daemons, so you should probably add a few more than this metric would indicate.
On many systems, you must tweak one of the /etc/rc* files or one of the rc files run by init to set the number of nfsds. Other systems provide a more elegant way to set this value.
Under Solaris, nfsd should be started with the -a option to enable service via both TCP and UDP. This is the default.
Under HP-UX, you can set the number of nfsds by setting the NUM_NFSD variable in /etc/rc.config.d/nfsconf to the value you want.
Under FreeBSD, nfsd should be given the -t and -u flags to request both TCP and UDP service. The FreeBSD version of nfsd also requires that the nfsd count be preceded by the -n flag (for example, nfsd -t -u -n 8). The command-line arguments with which nfsd is started come from the variable nfs_server_flags in /etc/rc.conf (or /etc/defaults/rc.conf if you don’t set it yourself; the default is “-u -t -n 4”). You must also set the nfs_server_enable variable to “YES” to start the NFS daemons.
17.3 CLIENT-SIDE NFS
mount understands the notation
hostname:directory
to mean the path directory interpreted by the host hostname.
The mount command and its associated NFS extensions represent the most significant concerns to a system administrator of an NFS client. On most systems, the optional but highly recommended daemon biod (block I/O daemon, sometimes called nfsiod) provides performance enhancements.
biod and nfsiod: provide client-side caching
biod/nfsiod performs basic read-ahead and write-behind filesystem block caching. Both NFSv2 and NFSv3 mounts can benefit from this daemon. We suggest that you run it on NFS clients that provide it, but that is not strictly required. The presence or absence of the caching daemon does not affect administration.
Like nfsd, biod takes as its argument the number of copies of itself to start. On a garden-variety machine, 4 or 8 copies should be plenty. If both nfsd and biod run on the same machine, it may be wise to split the “optimal” number of slots between them. This will depend on how your system is used; you’ll have to experiment.
Under FreeBSD, nfsiod needs a -n flag on the command line in front of the number of copies to run.
Mounting remote filesystems
You can use the mount command to establish temporary network mounts, but you should list mounts that are part of a system’s permanent configuration in /etc/fstab (/etc/vfstab in Solaris) so that they are mounted automatically at boot time. Alternatively, mounts can be handled by an automatic mounting service such as automount or amd; see Automatic mounting on page 504.
See page 504 for more information about automount and amd.
The following fstab entries mount the filesystems /beast/users and /usr/man from the hosts beast and chimchim:
# filesystem mountpoint fstype flags dump fsck
beast:/beast/users /beast/users nfs rw,bg,intr,hard 0 0
chimchim:/usr/man /usr/man nfs