Optimizing the transaction size
A transaction is a unit of work that is exchanged between a client and the server.
A client program can transfer more than one file or directory between the client and server before the client commits the data in the transaction to server storage. If a transaction contains more than one file or directory, it is called a transaction group.
Data in a transaction is sent from the client to the server during backup operations. Data in a transaction is sent from the server to the client during a restore operation.
You can control the amount of data that is sent between the client and server by setting the txnbytelimit client option. The server administrator can also limit the number of files or directories that are contained within a transaction group by setting the TXNGROUPMAX option.
These two options work together such that the size of any transaction is based on which of these parameter values is reached first. For example, if the TXNGROUPMAX option is set to 4096 and the txnbytelimit option is set to 25600 KB (25 MB), then up to 4096 small files can be included in a transaction if the sum of their sizes does not exceed 25600 KB. If objects are 25 MB in size, or larger, they are sent as one file in one transaction.
Changing how much data can be sent in a transaction affects the speed at which the client performs work. The default values are sufficient in most environments, except when the data is being written directly to a tape device. At the end of each transaction, the tape buffers must be written to physical media, which is a slow process; transferring more data with each transaction can improve performance when the server is writing data directly to tape.
- Increasing the amount of data per transaction increases the size of logs and log pools space on the server. Verify that you have enough free disk space to contain larger transaction logs and log pool space. Increasing log sizes can also cause longer server start times.
- Increasing the amount of data per transaction causes more data to be retransmitted if an error occurs. Resending data reduces performance, and resending larger transactions reduces performance even more.
- The benefits of changing the setting for the txnbytelimit option depend on the configuration and the type of workloads. In particular, increasing this value benefits tape storage pool backup more so than disk storage pool backup, especially if you are protecting many small files.
Consider setting a smaller txnbytelimit value if error conditions cause repeated retransmissions of transactions, when you specify static, shared static, or shared dynamic as the copy serialization attribute in the standard management class. A smaller txnbytelimit value applies to static and shared attributes. If a file changes during a backup operation and the client does not send it, the client still must resend the other files in that transaction.
To enhance performance, set the txnbytelimit option to 2 GB, and on the server, set the TXNGROUPMAX option to 256 KB. Additionally, for small file workloads, stage the backups to a disk storage pool and then migrate the files to tape.
For the txnbytelimit option, you can specify a value in the range 300 KB - 32 GB. The default value is 25600 KB.
Suggested settings for txnbytelimit
- txnbytelimit setting when backing up objects to disk before migrating them to tape:
txnbytelimit 25600K- txnbytelimit setting when backing up objects directly to tape:
txnbytelimit 10G
If you are using IBM
Storage Protect with the IBM® Content Manager application and you notice slow server data
movement operations, see the support article at technote 85953 for
information about using the CM VOL_AGGREGATESIZE setting in the CM
RMVOLUMES table to improve transaction performance.