MAN page from RedHat Other linux-nfs-clients-0.4.22-1.i386.rpm

NHFSSTONE

Section: User Commands (1)
Updated: 4 October 1989
Index

NAME

nhfsstone - Network File System benchmark program

SYNOPSIS

nhfsstone[-v] [[-t secs] | [-c calls]] [-l load] [-p nprocs] [-m mixfile] [dir]...

DESCRIPTION

nhfsstone(pronounced n-f-s-stone, the "h" is silent)is used on aNFSclient to generate an artificial load with a particular mix ofNFSoperations. It reports the average response time of the server inmilliseconds per call and the load in calls per second.The program adjusts its calling patterns based on the client's kernelNFSstatistics and the elapsed time.Load can be generated over a given time or number ofNFScalls.

Because it uses the kernelNFSstatistics to monitor its progress,nhfsstonecannot be used to measure the performance of non-NFS filesystems.

Thenhfsstoneprogram uses file and directory manipulation in an attempt to generateparticularNFSoperations in response to particular system calls.To do this it uses several tricksthat are based on a knowledge of the implementation of theNFSclient side reference port.For example, it uses long file names to circumvent the kernel name lookupcache so that astat(2)system call generates anNFSlookup operation.

The mix ofNFSoperations can be set with a mix file, which is the output of thenfsstat(8C)command (see the "-m" option below).The percentages taken fromthe mix file are calculated based on the number ofNFScalls, not on the percentages printed by nfsstat. Operations with0% in the mix will never get called bynhfsstone.In a real server load mix, even though the percentage of call fora particularNFSoperation may be zero, the number of calls is often nonzero.Nhfsstonemakes the assumption that the number of calls to these 0 percentoperations will have an insignificant effect on server response.

Normallynhfsstoneshould be given a list of two or more test directories to use(default is to use the current directory).The test directories used should be located on different disks andpartitions on the server to realistically simulate typical server loads.Eachnhfsstoneprocess looks for a directory<dir>/testdir<n>(where <n> is a number from 0 tonprocs- 1).If a process directory name already exists,it is checked for the correct set of test files.Otherwise the directory is created and populated.

OPTIONS

-v: Verbose output.
-t secs: Setscallsbased on the given running time (in seconds) and the load.
-c calls: Total number ofNFScalls to generate (default is 5000).
-l load: Load to generate inNFScalls per second (default is 30).
-p nprocs: Number of load generating sub-processes to fork (default is 7).This can be used to maximize the amount of load a single machine can generate.On a small client machine (slow CPU or small amount of memory)fewer processes might be used to avoid swapping.
-m mixfile: Mix ofNFSoperations to generate.The format ofmixfileis the same as the output of thenfsstat(8C)program.A mix file can be created on a server by typing "nfsstat -s > mixfile".The default mix of operations is: null 0%, getattr 13%, setattr 1%,root 0%, lookup 34%, readlink 8%, read 22%, wrcache 0%, write 15%, create 2%,remove 1%, rename 0%, link 0%, symlink 0%, mkdir 0%, rmdir 0%, readdir 3%,fsstat 1%.

USING NHFSSTONE

As with all benchmarks,nhfsstonecan only provide numbers that are useful if experiments that use it areset up carefully.Since it is measuring servers, it should be run on a clientthat will not limit the generation ofNFSrequests.This means it should have a fast CPU,a good ethernet interface and the machineshould not be used for anything else during testing.A Sun-3/50 can generate about 60NFScalls per second before it runs out of CPU.

Nhfsstoneassumes that allNFScalls generated on the client are going to a single server, and thatall of theNFSload on that server is due to this client.To make this assumption hold,both the client and server should be as quiescent as possible during tests.

If the network is heavily utilized the delays due to collisionsmay hide any changes in server performance.High error rates on either the client or server can alsocause delays due to retransmissions of lost or damaged packets.netstat(8C)-ican be used to measure the error and collision rates on the client and server.

To best simulate the effects ofNFSclients on the server, the testdirectories should be set up so that they are on at least two of thedisk partitions that the server exports and the partitions should beas far apart as possible. Thedkinfo(8)command can be used to find the physical geometry of disk on BSD based systems.NFSoperations tend to randomizeaccess the whole disk so putting all of thenhfsstonetest directories on a single partition or ontwo partitions that are close together will not show realistic results.

On all tests it is a good idea to run the tests repeatedly and compare results.The number of calls can be increased(with the-coption) until the variance in milliseconds per call is acceptably small.If increasing the number of calls does not help there may be somethingwrong with the experimental setup.One common problem is too much memory on the clienttest machine. With too much memory,nhfsstoneis not able to defeat the client caches and theNFSoperations do not end up going to the server at all. If you suspect thatthere is a caching problem you can use the-poption to increase the number of processes.

The numbers generated bynhfsstoneare most useful for comparison if the test setup on the client machineis the same between different server configurations. Changingnhfsstoneparameters between runs will produce numbers that can not bemeaningfully compared.For example, changing the number of generator processesmay affect the measured responsetime due to context switching or other delays on the client machine, whilechanging the mix ofNFSoperations will change the whole nature of the experiment.Other changes to the client configuration may also effect the comparabilityof results.Whilenhfsstonetries to compensate for differences in client configurationsby sampling the actualNFSstatistics and adjusting both the load and mix of operations, some changesare not reflected in either the load or the mix. For example, installinga faster CPU or mounting differentNFSfilesystems may effect the response time without changing either theload or the mix.

To do a comparison of different server configurations, first set up theclient test directories and donhfsstoneruns at different loads to be sure that the variability isreasonably low. Second, runnhfsstoneat different loads of interest andsave the results. Third, change the server configuration (for example,add more memory, replace a disk controller, etc.). Finally, run the samenhfsstoneloads again and compare the results.

ERROR MESSAGES

illegal calls value: The callsargument following the-cflag on the command line is not a positive number.
illegal load value: Theloadargument following the-lflag on the command line is not a positive number.
illegal time value: Thetimeargument following the-tflag on the command line is not a positive number.
bad mix file: Themixfilefile argument following the-mflag on the command line could not be accessed.
can't find current directory: The parent process couldn't find the pathname of the current directory.This usually indicates a permission problem.
can't fork: The parent couldn't fork the child processes. This usually results fromlack of resources, such as memory or swap space.
: can't open log file
can't stat log
can't truncate log
can't write sync file
can't write log
can't read log: A problem occurred during the creation, truncation, reading or writing of thesynchronization log file. The parent process creates thelog file in /tmp and uses it to synchronize and communicate with its children.
: can't open test directory
can't create test directory
can't cd to test directory
wrong permissions on test dir
can't stat testfile
wrong permissions on testfile
can't create rename file
can't create subdir: A child process had problems creating or checking the contents of itstest directory. This is usually due to a permission problem (for examplethe test directory was created by a different user) or a full filesystem.
: bad mix format: unexpected EOF after 'nfs:'
bad mix format: can't find 'calls' value
bad mix format: unexpected EOF after 'calls'
bad mix format: can't find %d op values
bad mix format: unexpected EOF: A problem occurred while parsing themixfile. The expected format of the file is the same as the output ofthenfsstat(8C)command when run with the "-s" option.
op failed:: One of the internal pseudo-NFS operations failed. The name of the operation,e.g. read, write, lookup, will be printed along with an indication of thenature of the failure.
select failed: The select system call returned an unexpected error.

BUGS

Runningnhfsstoneon a non-NFS filesystem can cause the program to run forever because ituses the kernel NFS statistics to determine when enough calls have been made.

Nhfsstoneuses many file descriptors. The kernel on the client mayhave to be reconfigured to increase the number of available file table entries.

Shell scripts that usednhfsstonewill have to catch and ignore SIGUSR1 (seesignal(3)).This signal isused to synchronize the test processes. If the signal is not caughtthe shell that is running the script will be killed.

FILES

/vmunix: system namelist
/dev/kmem: kernel virtual memory
./testdir*: per process test directory
/tmp/nhfsstone%d: process synchronization log file

This document was created byman2html,using the manual pages.