Партнёры:
Хостинг:
nhfsstone - Network File System benchmark program
Because it uses the kernel NFS statistics to monitor its progress, nhfsstone cannot be used to measure the performance of non-NFS filesystems.
The nhfsstone program uses file and directory manipulation in an attempt to generate particular NFS operations in response to particular system calls. To do this it uses several tricks that are based on a knowledge of the implementation of the NFS client side reference port. For example, it uses long file names to circumvent the kernel name lookup cache so that a stat(2) system call generates an NFS lookup operation.
The mix of NFS operations can be set with a mix file, which is the output of the nfsstat(8C) command (see the "-m" option below). The percentages taken from the mix file are calculated based on the number of NFS calls, not on the percentages printed by nfsstat. Operations with 0% in the mix will never get called by nhfsstone. In a real server load mix, even though the percentage of call for a particular NFS operation may be zero, the number of calls is often nonzero. Nhfsstone makes the assumption that the number of calls to these 0 percent operations will have an insignificant effect on server response.
Normally nhfsstone should 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 and partitions on the server to realistically simulate typical server loads. Each nhfsstone process looks for a directory <dir>/testdir<n> (where <n> is a number from 0 to nprocs - 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.
Nhfsstone assumes that all NFS calls generated on the client are going to a single server, and that all of the NFS load 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 collisions may hide any changes in server performance. High error rates on either the client or server can also cause delays due to retransmissions of lost or damaged packets. netstat(8C) -i can be used to measure the error and collision rates on the client and server.
To best simulate the effects of NFS clients on the server, the test directories should be set up so that they are on at least two of the disk partitions that the server exports and the partitions should be as far apart as possible. The dkinfo(8) command can be used to find the physical geometry of disk on BSD based systems. NFS operations tend to randomize access the whole disk so putting all of the nhfsstone test directories on a single partition or on two 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 -c option) until the variance in milliseconds per call is acceptably small. If increasing the number of calls does not help there may be something wrong with the experimental setup. One common problem is too much memory on the client test machine. With too much memory, nhfsstone is not able to defeat the client caches and the NFS operations do not end up going to the server at all. If you suspect that there is a caching problem you can use the -p option to increase the number of processes.
The numbers generated by nhfsstone are most useful for comparison if the test setup on the client machine is the same between different server configurations. Changing nhfsstone parameters between runs will produce numbers that can not be meaningfully compared. For example, changing the number of generator processes may affect the measured response time due to context switching or other delays on the client machine, while changing the mix of NFS operations will change the whole nature of the experiment. Other changes to the client configuration may also effect the comparability of results. While nhfsstone tries to compensate for differences in client configurations by sampling the actual NFS statistics and adjusting both the load and mix of operations, some changes are not reflected in either the load or the mix. For example, installing a faster CPU or mounting different NFS filesystems may effect the response time without changing either the load or the mix.
To do a comparison of different server configurations, first set up the client test directories and do nhfsstone runs at different loads to be sure that the variability is reasonably low. Second, run nhfsstone at different loads of interest and save the results. Third, change the server configuration (for example, add more memory, replace a disk controller, etc.). Finally, run the same nhfsstone loads again and compare the results.
The nhfsstone.c source file has comments that describe in detail the operation of of the program.
Running nhfsstone on a non-NFS filesystem can cause the program to run forever because it uses the kernel NFS statistics to determine when enough calls have been made.
Nhfsstone uses many file descriptors. The kernel on the client may have to be reconfigured to increase the number of available file table entries.
Shell scripts that used nhfsstone will have to catch and ignore SIGUSR1 (see signal(3)). This signal is used to synchronize the test processes. If the signal is not caught the shell that is running the script will be killed.
|
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |