TSATEST Readme for Linux
July 27, 2007
TSATEST is a tool designed to analyze the performance characteristics of SMS®. In particular, it performs statistical analysis of the backup functions being used. As a consequence, it can be considered as a useful tool for troubleshooting backup problems.
TSATEST does not actually save the data being backed up. It demonstrates what could be delivered from the SMS components as if an infinitely fast, zero latency archive device is being used. TSATEST determines if the SMS components are a causal factor in poor backup performance as it best uses SMS APIs eliminating other bottlenecks. It also helps to compare SMS capabilities with the actual backup performance.
Download the novell-sms rpm under dependencies section in SMS Developer Components .
Install the novell-sms rpm and start SMS Services. Refer the readme for instructions.
Use make to build using the sample Makefile. Makefile is available at /opt/novell/samples/sms/tsatest.
Execute ./tsatest
TSATEST can be launched from the server console. The configuration is performed using command line parameters. If the same option is repeated in the command line, the last option specified overrides others.
To run TSATEST type the following at the shell prompt:
./tsatest [ Parameters as needed]
The following table provides the details about the various parameters, the corresponding descriptions and the default values. In this table, items enclosed in square brackets [] are optional. Items in boldface are of two types.
short options(items prefixed by single hyphen) are case-sensitive
long options(items prefixed by double hyphen) are case-insensitive
Items in italics represent variable text that should be replaced with something appropriate for your own environment. For example, a volume name, a server name etc.
Parameter |
Default |
Description |
---|---|---|
-s Server |
Local server |
Specifies the server to backup. DNS name of server can also be specified. This is required for backing up data on a remote server. |
-v Volume/Resource |
SYS: |
Specify the volume name to backup for NetWare targets. This option should be used only for NetWare targets. |
--path= Path |
No default |
Specify the path to backup. On Linux this is the fully qualified path from the root file system. For NetWare targets, this is a path without the volume name, use -v to specify the volume. |
-u Username |
No default |
Specify the user name to connect to the target service. This is the user name on the Linux server for Linux targets and is fully distinguished name of the user for NetWare targets. |
-p Password |
No default |
Specifies the password to be used when authenticating with the TSA (See Known Issues) |
--log[= LogFile] |
tsatest.log in the present working directory |
Create a log of statistical data gathered during job execution. Any existing log file is over-written. |
-i Iterations |
1 |
Specifies a number of times to execute a particular job in succession. For example, -i 10 will cause the specified job to execute 10 times. NOTE:If the entire job fits in the server cache memory remaining iterations may show much faster performance due to the file system cache |
--size=DataSetSize |
No default |
Specifies the total size of all data that will be backed up. This option can be used only with the --pres option because it enables a progress bar that is displayed only in the in --pres mode. |
--pres |
OFF |
Enables presentation mode. In this mode, the rolling log is not displayed, the aggregate performance is displayed in large characters and, if the --size= option is used a progress bar is displayed. |
--shownames |
OFF |
Display filenames while enumerating the job. |
-c ScanTypeNumber |
0 |
Specifies a value to be used in the scanType field of the job structure when creating a job. This option should only be used after referring to the SMS NDK documentation for appropriate values.The -c option can also be used to perform tasks such as incremental backup, backup trustee information, data streams etc. |
-err= ErrLogFile |
No default |
Specifies a filename in which to list all errors reported during the backup. Any existing file is overwritten. |
--agg |
OFF |
Specifies the aggregate statistical data across multiple iterations. This switch is related to the -i option. |
--fulllog |
OFF |
Sets the rolling log display to report the result of all operations rather than informational and error messages only. |
-g GrowAmount |
No default |
Specifies a method for growing the read buffer size on each iteration. Currently, two syntaxes are supported. If a number is specified then the buffer is increased by the specified number of bytes on each iteration. If an X is succeeded by a specific number, e.g. -g X2, then the buffer is multiplied by the specified number on each iteration. This switch is related to the -i option. |
--ms |
OFF |
Uses millisecond rather than 0.1ms resolution timing. Only useful for comparing data gathered by other programs if they support millisecond timing |
--microsec |
OFF |
Uses microsecond rather than 0.1ms resolution timing. Only useful for comparing data gathered by other programs if they support microsecond timing. |
--cluster |
OFF |
Performs backup using the cluster file system TSA rather than the standard file system TSA. This allows access to TSA resources exposed only via the cluster target service. TSATEST does not support failover/failback. |
--nowaitonexit |
OFF |
Causes TSATEST to exit automatically. Without this argument tsatest waits for a key to be pressed before exiting (thus permitting the review of the statistics on screen). The default behavior makes it difficult to use TSATEST in unattended scenarios. |
--ave [=Tolerence[,Group Length[,Filename]]] |
10%, 64, tsatest.ave in the present working directory |
Enables moving average analysis. This is very useful for investigating how performance varies throughout a backup job. The tolerance defines the range across which the moving average is considered to be unchanged. The group length is the number of files in the group used to calculate the moving average. The filename permits the specification of an alternative output location to the default. Any existing file is over-written. For more details, refer Moving Average File Format. |
--bucketCount |
32 |
Specify the maximum number of histogram buckets |
--maxBucketValue |
128 |
Specify the maximum value for last histogram bucket |
--minBucketValue |
0 |
Specify the minimum value for first histogram bucket |
--version |
No default |
Displays the version. |
--help |
No default |
Displays a help page. |
tsatest -u root -p unsecure
Backs up the resource ’/ ’using the supplied credentials.
tsatest --path=/home -u root -p unsecure
Backs up the resource ‘/home' using the supplied credentials.
tsatest -s ACME_SERVER -v SYS: --path=SYSTEM -u root -p unsecure
Backs up the NetWare target SYS:\SYSTEM on ACME_SERVER using the supplied credentials.
tsatest -b 131072 -u root -p unsecure
Backs up the / resource using the supplied credentials and a buffer size of 131072 bytes.
tsatest -s ACME_SERVER -u root -p unsecure
Backs up the resource ’/ ’ on server ACME_SERVER using the supplied credentials. This will perform a remote backup if ACME_SERVER is not the server on which tsatest is loaded/executed.
tsatest --path=/proc/usb -u root -p unsecure -c 6144
Backs up the resource /proc/usb using the supplied credentials. Excludes all datastreams and extended attributes. The value 6144 is arrived by a bitwise ORing of the values for NWSM_EXCLUDE_EXTENDED_ATTRIBUTS (0x0800) and NWSM_EXCLUDE_DATA_STREAMS (0x1000).
tsatest --cluster -s CLUSTER_OBJECT_CLUSTERPOOL_SERVER
Backs up the NetWare virtual server node represented by CLUSTER_OBJECT_CLUSTERPOOL_SERVER.
tsatest --cluster -s CLUSTER_OBJECT_CLUSTERPOOL_SERVER -v RESOURCE_ON_THE_CLUSTER_POOL
Backs up the specified volume, ’RESOURCE_ON_THE_CLUSTER_POOL’ on the NetWare virtual server node represented by CLUSTER_OBJECT_CLUSTERPOOL_SERVER.
TSATEST screen is divided into two regions. The top half contains the statistics for the current job. The bottom half contains a rolling log of status information or, if --pres is used, the effective data rate and possibly a progress bar (if --size= is also used).
The log file produced by the --log argument is a comma-delimited text file that can be loaded into most spreadsheet application. The first line in the log file has the column headings for each row’s data entries. They map to the prime statistics described above. Following the prime statistics are a set of histogram data entries that require independent explanation. The prime statistics are as follows:
The remaining statistics are the histogram buckets for the primary SMS APIs: scan, open, read and close. Each histogram has user specified number of buckets (default: 32) representing a set of time values for execution of the corresponding API. The floor time value for the entire set of buckets is specified by minBucketValue(default:0) and the ceil time value by maxBucketValue (default:128).The value in each bucket is the number of executions of that API that fell within the time interval represented by that bucket. The time interval is a measure of bucket width, which is the ratio of (max-min)Bucket value and bucketCount. By default(bucketCount = 32, minBucketValue = 0, maxBucketValue = 128). The precise time interval for each bucket is as follows:
The moving average file produced by the --ave argument is also a comma-delimited text file that can be loaded into most spreadsheet application. The first line of the log file has the column headings for each row’s data entries. The file contains variable number of rows of data. As the job is executed the average performance for the most recent n files is tracked (where n is the group length). As each new file is added to the tracking list one is dropped from tracking. If the performance of the new group is within the tolerance parameters, a counter is incremented. If the performance exceeds the tolerance then the moving average statistics to that point are dumped to the file and the statistics are reset using the new performance as the baseline (and, thus, with a new range of values representing the tolerance).
For example, assuming the default values of 10% tolerance and a 64 file group length, let’s say that average the performance for the first 64 files is 1000MB/min. The range of tolerance values is 900MB/min through 1100MB/min. So, the next file is read and the statistics for the very first file are dropped and the latest file’s statistics replace them. Maybe the average performance is now 1001MB/min, this is still within the tolerance so the sample count is incremented and nothing else happens. On the next pass the second file recorded is dropped and it’s data replaced with that for the next file. Maybe the average performance drops to 850MB/min. Now we dump the statistics for the data so far and reset with a new baseline average performance of 850 MB/min and a sample count of 1. The new tolerance range is 765 MB/min through 935MB/min (10%). Three statistical values are dumped to the log file:
TSATEST should be used to analyze the behavior of backups and use that analysis to identify areas where the backup system is inadequate. Some points to note:
By the nature of its design, TSATEST is capable of extracting maximum performance that SMS can deliver. A commercial backup engine does not extract similar performance from SMS given that TSATEST does not perform any tape write operations among other differences in design. Where the archive device is faster than what TSATEST reports, then a commercial backup application can deliver more as a consequence of using multiple streams to tape (multiplexing).
An equally important consideration is the disk system itself. A 15 disk RAID-0 system is going to deliver greater throughput than a single disk IDE system.
A small mean file size makes the scan, open and close operations contribute a larger proportion to the total time spent on each object. This results in spending a large amount of time in these operations in comparison to the number of bytes that is read from the system. Hence, for a smaller mean file size it is normal to expect a lower performance than one with a larger mean file size.
Better TSATEST results in comparison to backup application throughput need not automatically imply poor backup application design. The vendor may sell many backup products, some aimed at the enterprise, some at the workgroup. Using a workgroup solution for enterprise storage will produce poor results.
Another consideration is the hardware used on the systems. For example, it is a fact that PCI bus has limits. Assuming you have 32 bit, 33MHz storage controllers and one PCI bus in your server then the maximum throughput you can reasonably expect is about 2.9GB/min, half the PCI bus capacity. This is because you have to read the data from disk across the PCI bus then write it back out to tape on the same PCI bus. The theoretical best performance is where each part of the operation uses exactly 50% of the bus capacity. So, if you see 5.3GB/min from TSATEST on a Linux server then you know that SMS can go as fast as the hardware is capable of.
A critical issue to consider is the extent to which file system caching affects performance. It is possible to get extraordinary results from TSATEST due to file system caching. The best way to prevent caching from being a factor is to define a backup job whose total size is larger than the installed memory used for cache on the server. So, for a server with 1GB memory, test with a backup job whose total size is larger than 1GB.
A single pass of TSATEST over a given resource is not sufficient analysis to make such judgments and care should be taken to perform a widespread analysis.
TSATEST does not modify any meta data or data on the system. Thus, running TSATEST will not affect features such as incremental backup.
Better TSATEST results in comparison to backup application throughput need not automatically imply poor backup application design. The vendor may sell many backup products, some aimed at the enterprise, some at the workgroup. Using a workgroup solution for enterprise storage may produce poor results.
If password is used as one of the parameters, then it will be displayed in clear text on the console. Thus, it is important to understand that this information is stored in the console’s command history. TSATEST with the -p parameter for password must only be used in circumstances where such a feature will not compromise overall network security.
Copyright © 2007 Novell, Inc. All rights reserved. No part of this publication may be reproduced, photocopied, stored on a retrieval system, or transmitted without the express written consent of the publisher. For Novell trademarks, see the Novell Trademark and Service Mark list. All third-party trademarks are the property of their respective owners. A trademark symbol (® , TM, etc.) denotes a Novell trademark; an asterisk (*) denotes a third-party trademark.