NetBackup™ Backup Planning and Performance Tuning Guide
- NetBackup capacity planning
- Primary server configuration guidelines
- Media server configuration guidelines
- NetBackup hardware design and tuning considerations
- About NetBackup Media Server Deduplication (MSDP)
- MSDP tuning considerations
- MSDP sizing considerations
- Accelerator performance considerations
- Media configuration guidelines
- How to identify performance bottlenecks
- Best practices
- Best practices: NetBackup AdvancedDisk
- Best practices: NetBackup tape drive cleaning
- Best practices: Universal shares
- NetBackup for VMware sizing and best practices
- Best practices: Storage lifecycle policies (SLPs)
- Measuring Performance
- Table of NetBackup All Log Entries report
- Evaluating system components
- Tuning the NetBackup data transfer path
- NetBackup network performance in the data transfer path
- NetBackup server performance in the data transfer path
- About shared memory (number and size of data buffers)
- About the communication between NetBackup client and media server
- Effect of fragment size on NetBackup restores
- Other NetBackup restore performance issues
- About shared memory (number and size of data buffers)
- Tuning other NetBackup components
- How to improve NetBackup resource allocation
- How to improve FlashBackup performance
- Tuning disk I/O performance
Issues uncovered by wait and delay counter values
You can correct issues by checking the following:
bptm-read waits
The bptm debug log contains messages such as the following:
...waited for full buffer 1681 times, delayed 12296 times
The first number is the number of times that bptm waited for a full buffer: in other words, how many times the bptm write operations waited for data from the source. If the wait counter indicates a performance issue, a change in the number of buffers does not help. Multiplexing may help if the target of the backup is tape.
In general, if the full buffer delays are substantially higher than the empty buffer delays, the network communication between the backup clients and the media server should be examined first to make sure that the full buffer delay is not caused by slow ingestion by the client. If network communication is not the issue, then the next step should be to examine the job detail report using bpdbjobs command. If the job report shows long delays between backup job starts and I/O writing starts, then loading the last backup image may be taking too long. In that case, disabling the last image loading may be the answer.
bptm-write waits
The bptm debug log contains messages such as the following:
...waited for empty buffer 1883 times, delayed 14645 times
The first number is the number of times that bptm waited for an empty buffer: the number of times bptm encountered data from the source faster than the data can be written to tape or disk. If the wait counter indicates a performance issue, reduce the multiplexing factor.
More buffers may help.
bptm delays
The bptm debug log contains messages such as the following:
...waited for empty buffer 1883 times, delayed 14645 times
The second number is the number of times that bptm waited for an available buffer. If the delay counter indicates a performance issue, investigate. Each delay interval is 30 microseconds.