1 .\" @(#)sfs.1 2.1 97/10/23
2 .\" See DESCR.SFS file for restrictions
4 .\" create man page by running 'tbl sfs.1 | nroff -man > sfs.cat'
6 .TH SFS 1 "5 October 1994"
8 SFS \- Network File System server benchmark program
40 .B \-M prime_client_hostname
75 .B server:/directory ...
108 .B \-M prime_client_hostname
143 .B server:/directory ...
150 script which controls
152 execution on one or more
154 client systems using a single user interface.
157 is a Network File System server benchmark.
158 It runs on one or more
160 client machines to generate an artificial load
161 consisting of a particular mix of
163 operations on a particular set of files
164 residing on the server being tested.
165 The benchmark reports the average response time of the
167 requests in milliseconds for the requested target load.
168 The response time is the dependent variable.
169 Load can be generated for a specific amount of time,
170 or for a specific number of
175 can also be used to characterize server performance.
176 Nearly all of the major factors that influence NFS performance
177 can be controlled using
179 command line arguments. Normally however, only the
182 Other commonly used options include the
189 The remaining options are used to adjust specific parameters that affect
192 If these options are used, the results produced will be non\-standard,
193 and thus, will not be comparable to tests run with other option settings.
197 is used as a benchmark program to measure the
200 of a particular server machine at different load levels.
202 the preferred measurement is to make a series of benchmark runs,
203 varying the load factor for each run
204 in order to produce a performance/load curve.
205 Each point in the curve
206 represents the server's response time at a specific load.
209 generates and transmits
211 packets over the network to the server directly from the benchmark program,
212 without using the client's local NFS service.
213 This reduces the effect of the client NFS implementation on results,
214 and makes comparison of different servers more client-independent.
215 However, not all client implementation effects have been eliminated.
216 Since the benchmark does by-pass much of the client NFS implementation
217 (including operating system level data caching and write behind),
219 can only be used to measure server performance.
223 can be run between a single client and single server pair of machines,
224 a more accurate measure of server performance is obtained
225 by executing the benchmark on a number of clients simultaneously.
226 Not only does this present a more realistic model of
228 usage, but also improves the chances that maximum performance
229 is limited by a lack of resources on the server machine,
230 rather than on a single client machine.
232 In order to facilitate running
234 on a number of clients simultaneously,
235 an accompanying program called
237 provides a mechanism to run and synchronize the execution of multiple
240 spread across multiple clients and multiple networks
241 all generating load to the same
246 should be used to run both single- and multiple-client tests.
249 employs a number of sub\-processes, each with its own test directory named
251 (where <n> is a number from 0 to
254 A standard set of files is created in the test directory.
258 are specified on the command line, the
260 processes will be evenly distributed among the directories.
261 This will produce a balanced load across each of the directories.
265 operations generated can be set from a user defined mix file.
266 The format of the file consists of a simple format, the first
267 line contains the string "SFS MIXFILE VERSION 2" followed by
268 each line containing the operation name and the percentage (eg.
269 "write 12"). The total percentages must equal 100.
270 Operations with not specified will never be called by
275 The percentage of I/O files to access.
276 The access percent can be set from 0 to 100 percent.
277 The default is 10% access.
280 The percentage of write operations that append data to files
281 rather than overwriting existing data.
282 The append percent can be set from 0 to 100 percent.
283 The default is 70% append.
286 The name of a file containing a block transfer size distribution specification.
287 The format of the file and the default values are discussed below
288 under "Block Size Distribution".
291 The maximum number of Kilo-bytes (KB) contained in any one data transfer block.
292 The valid range of values is from 1 to 8 KB.
293 The default maximum is 8 KB per transfer.
296 The debugging level, with higher values producing more debugging output.
297 When the benchmark is executed with debugging enabled,
298 the results are invalid.
299 The debug level must be greater than zero.
302 The number of files in each directory, the number of directories varies with
304 The default is 30 files per directory.
306 .B \-f file_set_delta
307 The percentage change in file set size.
308 The change percent can be set from 0 to 100 percent.
309 The default is 10% append.
312 The number of files to be used for read and write operations.
313 The file count must be greater than 0.
314 The default is 100 files.
317 Run the test in interactive mode,
318 pausing for user input before starting the test.
319 The default setting is to run the test automatically.
322 The number of NFS calls per second to generate from each client machine.
323 The load must be greater than the number of processes
324 (see the "\-p processes" option).
325 The default is to generate 60 calls/sec on each/client.
328 The name of a file containing the operation mix specification.
329 The format of the file and the default values are discussed below
330 under "Operation Mix".
333 The number of processes used to generate load on each client machine.
334 The number of processes must be greater than 0.
335 The default is 4 processes per client.
338 Populate the test directories and then exit; don't run the test.
339 This option can be used to examine the file set that the benchmark creates.
340 The default is to populate the test directories and then
341 execute the test automatically.
348 The maximum number of asynchronus reads issued to simulate biod behavior.
352 The number of symbolic links to be used for symlink operations.
353 The symbolic link count must be greater than 0.
354 The default is 20 symlinks.
357 The number of seconds to run the benchmark.
358 The number of seconds must be greater than 0.
359 The default is 300 seconds.
360 (Run times less than 300 seconds may produce invalid results.)
365 operation by executing it once.
366 The valid range of operations is from 1 to 23.
367 These values correspond to the procedure number
368 for each operation type as defined in the
370 protocol specification.
371 The default is to run the benchmark, with no preliminary operation testing.
374 Validate the correctness of the server's
377 The option verifies the correctness of
379 operations and data copies.
380 The verification takes place immediately before executing the test,
381 and does not affect the results reported by the test.
382 The default is not to verify server
384 operation before beginning the test.
387 Generate raw data dump of the individual data points
391 The number of seconds to generate load before starting the timed test run.
392 The goal is to reach a steady state and eliminate any variable startup costs,
393 before beginning the test.
394 The warm up time must be greater than or equal to 0 seconds.
395 The default is a 60 second warmup period.
398 The maximum number of asynchronus writes issued to simulate biod behavior.
400 .SH MULTI-CLIENT OPTIONS
402 also recognizes options that are only used when executing a multi-client test.
403 These options are generated by
405 and should not be specified by an end-user.
407 .B \-M prime_client_hostname
408 The hostname of the client machine where a multi-client test
409 is being controlled from.
410 This machine is designated as the "prime client".
411 The prime client machine may also be executing the
413 load-generating code. There is no default value.
416 The client machine's unique identifier within a multi-client test,
420 There is no default value.
422 .\".B \-R random_number_seed
423 .\"The value used by the client to index into a table of random number seeds.
424 .\"There is no default value.
428 default mix of operations for version 2 is:
438 null getattr setattr root lookup readlink
440 read wrcache write create remove rename
442 link symlink mkdir rmdir readdir fsstat
448 default mix of operations for version 3 is:
460 null getattr setattr lookup access readlink
462 read write create mkdir symlink mknod
464 remove rmdir rename link readdir readdirplus
466 fsstat fsinfo pathconf commit
470 The format of the file consists of a simple format, the first
471 line contains the string "SFS MIXFILE VERSION 2" followed by
472 each line containing the operation name and the percentage (eg.
473 "write 12"). The total percentages must equal 100.
475 The default basic file set used by
477 consists of regular files varying in size from 1KB to 1MB used for read and
479 and 20 symbolic links used for symbolic link operations.
480 In addition to these, a small number of regular files are created
481 and used for non-I/O operations (eg, getattr),
482 and a small number of regular, directory, and symlink files may
483 be added to this total due to creation operations (eg, mkdir).
485 While these values can be controlled with command line options,
486 some file set configurations may produce invalid results.
487 If there are not enough files of a particular type,
488 the specified mix of operations will not be achieved.
489 Too many files of a particular type may produce
490 thrashing effects on the server.
491 .SH BLOCK SIZE DISTRIBUTION
492 The block transfer size distribution is specified by a table of values.
493 The first column gives the percent of operations that will be included in a
494 any particular specific block transfer.
495 The second column gives the number of blocks units that will be transferred.
496 Normally the block unit size is 8KB.
497 The third column is a boolean specifying
498 whether a trailing fragment block should be transferred.
499 The fragment size for each transfer is a random multiple of 1 KB,
500 up to the block size - 1 KB.
501 Two tables are used, one for read operation and one for write operations.
502 The following tables give the default distributions
503 for the read and write operations.
513 Read - Default Block Transfer Size Distribution Table
516 percent block count fragment (8KB block size)
523 1 16 1 1% 128 - 135 KB
534 Write - Default Block Transfer Size Distribution Table
537 percent block count fragment (8KB block size)
544 1 16 1 1% 128 - 135 KB
547 A different distribution can be substituted by using the '-b' option.
548 The format for the block size distribution file consists of the first
549 three columns given above: percent, block count, and fragment. Read
550 and write distribution tables are identified by the keywords "Read" and
551 "Write". An example input file, using the default values, is given below:
576 A second aspect of the benchmark controlled
577 by the block transfer size distribution table is the network data packet size.
578 The distribution tables define the relative proportion
579 of full block packets to fragment packets.
580 For instance, the default tables have been constructed
581 to produce a specific distribution of ethernet packet sizes
582 for i/o operations by controlling the amount of data in each packet.
583 The write packets produced consist of 50% 8-KB packets, and 50% 1-7 KB packets.
584 The read packets consist of 90% 8-KB packets, and 10% 1-7 KB packets.
585 These figures are determined by multiplying the percentage
586 of type of transfer times the number of blocks and fragments generated,
587 and adding the totals.
588 These computations are performed below
589 for the default block size distribution tables:
604 percent blocks fragments blocks fragments
629 percent blocks fragments blocks fragments
641 As with all benchmarks,
643 can only provide numbers that are useful
644 if the test runs are set up carefully.
645 Since it measures server performance,
646 the client (or clients) should not limit throughput.
647 The goal is to determine how well the server performs.
648 Most tests involving a single client will be limited by the client's
649 ability to generate load, not by the server's ability to handle more load.
650 Whether this is the case can be determined by running the benchmark
651 at successively greater load levels and finding the "knee of the curve"
652 at which load level the response time begins to increase rapidly.
653 Having found the knee of the curve, measurements of CPU utilization,
654 disk i/o rates, and network utilization levels should be made in order
655 to determine whether the performance bottleneck is due to the client
658 For the results reported by
660 to be meaningful, the tests should be run on an isolated network,
661 and both the client and server should be as quiescent as possible during tests.
663 High error rates on either the client or server
664 can also cause delays due to retransmissions
665 of lost or damaged packets.
667 can be used to measure the network error
668 and collision rates on the client and server.
671 reports the number of timed-out
673 calls that occur during the test as bad calls.
674 If the number of bad calls is too great,
675 or the specified mix of operations is not achieved,
677 reports that the test run is "Invalid".
678 In this case, the reported results should be examined
679 to determine the cause of the errors.
681 To best simulate the effects of
683 clients on the server, the test
684 directories should be set up so that they are on at least two
685 disk partitions exported by the server.
687 operations tend to randomize disk access,
688 so putting all of the
690 test directories on a single partition will not show realistic results.
692 On all tests it is a good idea to run the tests repeatedly and compare results.
693 If the difference between runs is large,
694 the run time of the test should be increased
695 until the variance in milliseconds per call is acceptably small.
696 If increasing the length of time does not help,
697 there may be something wrong with the experimental setup.
699 The numbers generated by
701 are only useful for comparison if the test setup on the client machine
702 is the same across different server configurations.
707 parameters will produce numbers that can not be meaningfully compared.
708 Changing the number of generator processes may affect the measured response
709 time due to context switching or other delays on the client machine,
710 while changing the mix of
712 operations will change the whole nature of the experiment.
713 Other changes to the client configuration may also effect the comparability
716 To do a comparison of different server configurations, first set up the
717 client test directory and do
719 runs at different loads to be sure that the variability is
720 reasonably low. Second, run
722 at different loads of interest and
723 save the results. Third, change the server configuration (for example,
724 add more memory, replace a disk controller, etc.). Finally, run the same
726 loads again and compare the results.
731 file contains many pointers to other
732 files which provide information concerning SFS.
735 .B "illegal load value"
738 argument following the
740 flag on the command line is not a positive number.
742 .B "illegal procs value"
745 argument following the
747 flag on the command line is not a positive number.
749 .B "illegal time value"
752 argument following the
754 flag on the command line is not a positive number.
759 file argument following the
761 flag on the command line could not be accessed.
764 The parent couldn't fork the child processes. This usually results from
765 lack of resources, such as memory or swap space.
768 .B "can't open log file"
772 .B "can't truncate log"
774 .B "can't write sync file"
780 A problem occurred during the creation, truncation, reading or writing of the
781 synchronization log file. The parent process creates the
782 log file in /tmp and uses it to synchronize and communicate with its children.
785 .B "can't open test directory"
787 .B "can't create test directory"
789 .B "can't cd to test directory"
791 .B "wrong permissions on test dir"
793 .B "can't stat testfile"
795 .B "wrong permissions on testfile"
797 .B "can't create rename file"
799 .B "can't create subdir"
801 A child process had problems creating or checking the contents of its
802 test directory. This is usually due to a permission problem (for example
803 the test directory was created by a different user) or a full file system.
807 One of the internal pseudo\-NFS operations failed. The name of the operation,
808 e.g. read, write, lookup, will be printed along with an indication of the
809 nature of the failure.
812 The select system call returned an unexpected error.
816 can not be run on non\-NFS file systems.
819 Shell scripts that execute
821 must catch and ignore SIGUSR1, SIGUSR2, and SIGALRM, (see signal(3)).
822 These signals are used to synchronize the test processes.
823 If one of these signals is not caught,
824 the shell that is running the script will be killed.
829 per process test directory
832 child process synchronization file
838 prime client log file
841 prime results log file
projects / bluesky.git / blob