IBM Support

Interpreting dsminstr reports from TESTFLAG INSTRUMENT:API

Technote (FAQ)


How do you interpret and use the data generated by the use of the TESTFLAG INSTRUMENT:API performance tracing?


A typical may look like the output below.
TSM Client final instrumentation statistics: Fri Dec  9 00:28:08 2016
Instrumentation class: API
Completion status: Success
Detailed Instrumentation statistics for
Thread: 1  Elapsed time =     8.918 sec
Section                Actual(sec) Average(msec) Frequency used
Waiting on App            4.895          0.6         7825
API Send Data             3.913          0.5         7815
API Query                 0.001          0.1            4
API End Txn               0.025         25.3            1
API Misc                  0.005          1.6            3
Other                     0.079          0.0            0

The first thing to check is that this report is for a session that was transferring data to the IBM Spectrum Protect server. This is done by looking at the Frequency used column, if it reports a large number (100 or more) for Waiting on App and API Send Data, then it did send data to the server.

Next review the Average (msec) column for the same 2 rows, Waiting on App measures how long it takes for the API to receive a packet of data from the application sending it, or in other words how quickly the application (DB2, Exchange, SQL, etc...) is sending data to the API. While API send data measures how quickly the API is sending that data across the network to the server (or for lanfree to the Storage Agent).

If the average time for the Waiting on App is the larger value, then the application sending the data is the slowest part of the backup. If this is the case then no increase in the performance of sending the data to the server or in the server writing that data to the storage media will improve the performance of the backup. Attention should be turned to improving the application's performance.

Conversely, if the API send Data Average is larger, then the slow part of the backup is the sending/writing the data to the server. When this is the case it maybe the network between the client and the server that is slow or it may be that the write of the data at the server is slower then the network. To check on the later, review the server performance data (or if not already gathered, gather new data with concurrent client and server data capture) to determine the bottleneck. If the server write speeds for the data are better then the network speed then attention should focus on improving the network through put.

Finally if the data is being sent via lanfree, then the API Send Data is the speed with which the API is sending the data to the Storage Agent. If this is the case then as above review the performance data from the Storage Agent, and if the write to the SAN attached drives is slower then the Network Recv speed, then the performance of the write speed should be analyzed. If the write to the drives is better then the Network Recv speed, this would indicate the transfer of the data within the Operating System is the bottleneck. In this case, ensure that all the latest OS patches are loaded, specifically those related to TCP/IP or other network communications and/or consider changing the protocol for the API to STA communications method from TCPIP to SharedMem (or vice versa).

Product Alias/Synonym

TSM Tivoli Storage manager

Document information

More support for: Tivoli Storage Manager

Software version: Version Independent

Operating system(s): Platform Independent

Reference #: 1980344

Modified date: 28 December 2016

Translate this page: