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
About the NOSHM file
Each time a backup runs, NetBackup checks for the existence of the NOSHM file. No services need to be stopped and started for it to take effect. You might use NOSHM, for example, when the NetBackup server hosts another application that uses a large amount of shared memory, such as Oracle.
NOSHM is also useful for testing: both as a workaround while solving a shared memory issue, and to verify that an issue is caused by shared memory.
Note:
NOSHM only affects operations when the client host is the media server.
NOSHM forces a local backup to run as though it were a remote backup. A local backup is a backup of a client that has a directly-attached storage unit. An example is a client that happens to be a primary server or media server. A remote backup passes the data across a network connection from the client to a primary server's or media server's storage unit.
A local backup normally has one or more client processes, for example bpbkar, that read from the disk and write into shared memory. A local backup also has a bptm process that reads from shared memory and writes to the storage media. A remote backup has one or more bptm (child) processes that read from a socket connection to bpbkar and write into shared memory. A remote backup also has a bptm (parent) process that reads from shared memory and writes to the storage media. NOSHM forces the remote backup model even when the client and the media server are the same system.
For a local backup without NOSHM, shared memory is used between bptm and bpbkar. Whether the backup is remote or local, and whether NOSHM exists or not, shared memory is always used between bptm (parent) and bptm (child).
Note:
NOSHM does not affect the shared memory that bptm uses to buffer the data that is written to tape or disk. bptm uses shared memory for any backup, local or otherwise.