CONFIDENTIAL - NOT FOR DISTRIBUTION
17Appendix CImproving NetBackup PerformanceC–13Determining waits and delaysWhen you are trying to determine where a bottleneck is for a given operation, start by reviewing the wait count on each side of the shared buffer. For a backup operation, the producer wait count is found in the bpbkarlog (even if a bptmchild is the actual producer), and the consumer wait count is found in the bptmlog. Starting in NetBackup 7.1, this information can also be found in the try logs, which are also shown in the job details for the backup job.Next, classify the results as low or high. The classification is relative to the amount of data transferred. Express the number as a percentage to obtain a measurable result using the formulas in the slide. In the example on the slide, 35 MB of data is transferred, the block size is 256K, and the total number of data buffers is 138.35,280K / 256K = 137.8 blocksCalculate the wait percentage as follows:•Producer: 0 waits / 138 = 0 percent waits•Consumer: 122 waits / 138 = 88.4 percent waitsAs a general guideline, values greater than 5 percent for large operations are considered high.Copyright © 2013 Symantec Corporation. All rights reserved.CONFIDENTIAL - NOT FOR DISTRIBUTION
18C–14Symantec NetBackup 7.5: Maintain and TroubleshootInterpreting backup waits Classify the data buffer waits and delays for a backup operation as follows:•Producer low, consumer lowThe throughput of the stream from the client and the speed of the tape device are roughly equal. The tape device must write at or near its real-world capacity.•Producer low, consumer highThe data stream is failing to provide data to the tape device quickly enough. First, optimize performance at the individual stream level, ensuring that the client can provide data to the media server as quickly as possible. If the condition still exists, increase the multiplexing level until it is resolved.•Producer high, consumer lowThe tape device is not writing as quickly as the data is being provided. This is a normal or even ideal condition in many cases, because the tape device is the primary bottleneck. In this situation, decrease the multiplexing value and verify whether the tape device is still the bottleneck. If throughput is not as high as expected, increase the data buffer size (within OEM recommendations), or update the tape device driver and firmware.•Producer high, consumer highThe bottleneck shifts between the tape device and the speed of the data stream. This may indicate a fast but unreliable data stream, resulting from a congested network or a very active client. Determine why the data stream is inconsistent and try increasing the number of data buffers. The primary goal is to reduce waits on the consumer side.
You've reached the end of your free preview.
Want to read all 158 pages?
- Fall '18
- Wing Wah
- ........., Symantec Corporation