OverviewThis chapter contains information on ways to optimize NetBackup. This chapter is not intended to provide tuning advice for particular systems.
If you would like help fine-tuning your NetBackup installation, please contact the VERITAS Consulting Services.
Before examining the factors that affect backup performance, please note that an important first step is to ensure that your system meets NetBackup’s recommended minimum requirements. Refer to the NetBackup Installation Guide and NetBackup Release Notes for information about these requirements. Additionally, VERITAS recommends that you have the most recent NetBackup software patch installed.
Many performance issues can be traced to hardware or other environmental issues. A
basic understanding of the entire data transfer path is essential in determining the
maximum obtainable performance in your environment. Poor performance is often the
result of poor planning, which can be based on unrealistic expectations of any particular
component of the data transfer path.
The data transfer path
The component that limits the overall performance of NetBackup is of course the slowest
component in the backup system. For example, a fast tape drive combined with an
overloaded server yields poor performance. Similarly, a fast tape drive on a slow network
also yields poor performance.
The backup system is referred to as the data transfer path. The path usually starts at the
data on the disk and ends with a backup copy on tape or disk.
This chapter subdivides the standard NetBackup data transfer path into four basic
components: the NetBackup client, the network, the NetBackup server, and the storage
device.
Note: This chapter discusses NetBackup performance evaluation and improvement from
a testing perspective. It describes ways to isolate performance variables in order to
get a sense of the effect each variable has on overall system performance, and to
optimize NetBackup performance with regard to that variable. It may not be
possible to optimize every variable on your production system.
The requirements for database backups may not be the same as for file system
backups. This information applies to file system backups unless otherwise noted.
Basic tuning suggestions for the data path
In every backup system there is always room for improvement. Obtaining the best
performance from a backup infrastructure is not complex, but it requires careful review of
the many factors that can affect processing. The first step is to gain an accurate assessment
of each hardware, software, and networking component in the backup data path. Many
performance problems are resolved before attempting to change NetBackup parameters.
NetBackup software offers plenty of resources to help isolate performance problems and
assess the impact of configuration changes. However, it is essential to thoroughly test both
backup and restore processes after making any changes to the NetBackup configuration
parameters.
Tuning suggestions:
Multiplexing is a NetBackup option that lets you write multiple data streams from
several clients at once to a single tape drive or several tape drives. Multiplexing can be
used to improve the backup performance of slow clients, multiple slow networks, and
many small backups (such as incremental backups). Multiplexing reduces the time
each job spends waiting for a device to become available, thereby making the best use
of the transfer rate of your storage devices.
Multiplexing is not recommended when restore speed is of paramount interest or
when your tape drives are slow. To reduce the impact of multiplexing on restore
times, you can improve your restore performance by reducing the maximum
fragment size for the storage units. If the fragment size is small, so that the backup
image is contained in several fragments, a NetBackup restore can quickly skip to the
specific fragment containing the file to be restored. In contrast, if the fragment size is
large enough to contain the entire image, the NetBackup restore starts at the very
beginning of the image and reads through the image until it finds the desired file.
Multiplexed backups can be de-multiplexed to improve restore performance by using
bpduplicate to move fragmented images to a sequential image on a new tape.
Consider striping a disk volume across drives.
A striped set of disks will pull data from all disk drives concurrently, allowing faster data transfers between disk drives and tape drives.
Maximize the use of your backup windows.
You can configure all your incremental backups to happen at the same time every day
and stagger the execution of your full backups across multiple days. Large systems
could be backed up over the weekend while smaller systems are spread over the
week. You can even start full backups earlier than the incremental backups. They
might finish before the incremental backups and give you back all or most of your
backup window to finish the incremental backups.
Convert large clients into media servers to decrease backup times and reduce network
traffic.
Any machine with locally-attached drives can be used as a media server to back up
itself or other systems. By converting large client systems into media servers, your
backup data no longer travels over the network (except for catalog data), and you get
the fastest transfer speeds afforded by locally-attached devices. Another benefit of
media servers is that you can use them to balance the load of backing up other clients
for your NetBackup master. A media server can back up clients on a network where it
has a local connection, thus saving network traffic for a master tha t might have to go
over routers to communicate with those clients. A special case of a media server is a
SAN Media Server, which is a NetBackup media server that backs up itself only and
comes at a lower cost than a regular media server.
Use dedicated private networks to decrease backup times and network traffic.
If you configure one or more networks dedicated to backups, you can reduce the time
it takes to back up the systems on those networks and reduce or eliminate network
traffic on your enterprise networks. In addition, you can convert to faster technologies
and even backup your systems at any time without affecting the enterprise network’s
performance (assuming that users do not mind the system loads while backups take
place).
Avoid a concentration of servers on one network.
If you have a concentration of large servers that you back up over the same general
network, you might want to convert some of these into media servers or attach them
to private backup networks. Doing either will decrease backup times and reduce
network traffic for your other backups.
Use dedicated backup servers to perform your backups.
When selecting a server for performing your backups, use a dedicated system just for
performing backups. A server that shares the load of running several applications
unrelated to backups can severely affect your performance and maintenance
windows.
Use drives from tape libraries attached to other systems.
You can use tape drives from a tape library attached to your master server or another
media server, or you can dedicate a library to your large servers. Systems using these
drives become media servers that can back up themselves and others through
locally-attached drives. The robotic control arm of the library can be connected to
either the master server or the media server.
Consider the requirements of backing up your catalog.
Remember that the NetBackup catalog needs to be backed up. To facilitate NetBackup
catalog recovery, it is highly recommended that the master server have access to a
dedicated tape drive, either standalone or within a robotic library.
Try to level the backup load.
You can use multiple drives to reduce ba ckup times; however, since you may not be
able to split data streams evenly, you may need to experiment with the configuration
of the streams or the configuration of the NetBackup policies to spread the load across
multiple drives.
Bandwidth limiting
The bandwidth limiting feature lets you restrict the network bandwidth consumed by
one or more NetBackup clients on a network. The bandwidth setting appears under
Host Properties > Master Servers, Properties. The actual limiting occurs on the client
side of the backup connection. This feature only restricts bandwidth during backups.
Restores are unaffected.
When a backup starts, NetBackup reads the bandwidth limit configuration and then
determines the appropriate bandwidth value and passes it to the client. As the
number of active backups increases or decreases on a subnet, NetBackup dynamically
adjusts the bandwidth limiting on that subnet. If additional backups are started, the
NetBackup server instructs the other NetBackup clients running on that subnet to
decrease their bandwidth setting. Similarly, bandwidth per client is increased if the
number of clients decreases. Changes to the bandwidth value occur on a periodic
basis rather than as backups stop and start. This characteristic can reduce the number
of bandwidth value changes.
NetBackup provides ways to balance loads between servers, clients, policies, and
devices. Note that these settings may interact with each other: compensating for one
issue can cause another. The best approach is to use the defaults unless you anticipate
or encounter an issue.
Adjust the backup load on the server.
Change the Limit jobs per policy attribute for one or more of the policies that the
server is backing up. For example, decreasing Limit jobs per policy reduces the
load on a server on a specific subnetwork. Reconfiguring policies or schedules to
use storage units on other servers also reduces the load. Another p ossibility is to
use bandwidth limiting on one or more clients.
Adjust the backup load on the server during specific time periods only.
Reconfigure schedules that execute during the time periods of interest, so they
use storage units on servers that can handle the load (assuming you are using
media servers).
Adjust the backup load on the clients.
Change the Maximum jobs per client global attribute. For example, increasing
Maximum jobs per client increases the number of concurrent jobs that any one
client can process and therefore increases the load.
Reduce the time to back up clients.
Increase the number of jobs that clients can perform concurrently, or use
multiplexing. Another possibility is to increase the number of jobs that the server
can perform concurrently for the policy or policies that are backing up the clients.
Give preference to a policy.
Increase the Limit jobs per policy attribute value for the preferred policy relative
to other policies. Alternatively, increase the priority for the policy.
Adjust the load between fast and slow networks.
Increase the values of Limit jobs per policy and Maximum jobs per client for the
policies and clients on a faster network. Decrease these values for slower
networks. Another solution is to use bandwidth limiting.
Limit the backup load produced by one or more clients.
Use bandwidth limiting to reduce the bandwidth used by the clients.
Maximize the use of devices
Use multiplexing. Also, allow as many concurrent jobs per storage unit, policy,
and client as possible without causing server, client, or network performance
issues.
Prevent backups from monopolizing devices.
Limit the number of devices that NetBackup can use concurrently for each policy
or limit the number of drives per storage unit. Another approach is to exclude
some of your devices from Media Manager control.
This section lists some factors to consider when evaluating the NetBackup client
component of the NetBackup data transfer path. Examine these conditions to identify
possible changes that may improve the overall performance of NetBackup.
Disk fragmentation. Fragmentation is a condition where data is scattered around the
disk in non-contiguous blocks. This condition severely impacts the data transfer rate
from the disk. Fragmentation can be repaired using hard disk management utility
software offered by a variety of vendors.
Number of disks. Consider adding additional disks to the system to increase
performance. If multiple processes are attempting to log data simultaneously,
dividing the data among multiple physical disks may help.
Disk arrays. Consider converting to a system ba sed on a Redundant Array of
Inexpensive Disks (RAID). Though more expensive, RAID devices generally offer
greater throughput, and, (depending on the RAID level employed), improved
reliability.
The type of controller technology being used to drive the disk. Consider if a different system
would yield better results.
Virus scanning. If virus scanning is turned on for the system, it may severely impact
the performance of the NetBackup client during a backup or restore operation. This
may be especially true for systems such as large Windows file servers. You may wish
to disable virus scanning during backup or restore operations to avoid the impact on
performance.
NetBackup notify scripts. The bpstart_notify.bat and bpend_notify.bat
scripts are very useful in certain situations, such as shutting down a running
application to back up its data. However, these scripts must be written with care to
avoid any unnecessary lengthy delays at the start or end of the backup job. If the
scripts are not performing tasks essential to the backup operation, you may want to
remove them.
NetBackup software location.
If the data being backed up is located on the same physical
disk drive as the NetBackup installation, performance may be adversely affected,
especially if NetBackup debug log files are being used. If they are being used, the
extent of the degradation will be greatly influenced by the NetBackup verbose setting
for the debug logs. If possible, install NetBackup on a separate physical disk drive to
avoid this disk drive contention.
Snapshots (hardware or software). If snapshots need to be taken before the actual backup
of data, the time needed to take the snapshot will affect the overall performance.
Job tracker. If the NetBackup Client Job Tracker is running on the client, then
NetBackup will gather an estimate of the data to be backed up prior to the start of a
backup job. Gathering this estimate will affect the startup time, and therefore the data
throughput rate, because no data is being written to the NetBackup server during this
estimation phase. You may wish to avoid running the NetBackup Client Job Tracker to
avoid this delay.
Client location. You may wish to consider adding a locally attached tape device to the
client and changing the client to a NetBackup media server if you have a substantial
amount of data on the client. For example, backing up 100 gigabytes of data to a
locally attached tape drive will generally be more efficient than backing up the same
amount of data across a network connection to a NetBackup server. Of course, there
are many variables to consider, such as the bandwidth available on the network, that
will affect the decision to back up the data to a locally attached tape drive as opposed
to moving the data across the network.
Determining the theoretical performance of the NetBackup client software. You can use the
NetBackup client command bpbkar (UNIX) or bpbkar32 (Windows) to determine
the speed at which the NetBackup client can read the data to be backed up from the
disk drive. This may eliminate data read speed as a possible performance bottleneck.
To improve the overall performance of NetBackup, consider the following network
components and factors.
Network interface settings
Network interface cards (NICs) for NetBackup servers and clients must be set to
full-duplex.
Both ends of each network cable (the NIC card and the switch) must be set identically
as to speed and mode (both NIC and switch must be at full duplex). Otherwise, link
down, excessive/late collisions, and errors will result.
If auto-negotiate is being used, make sure that both ends of the connection are set at
the same mode and speed. The higher the speed, the better.
In addition to NICs and switches, all routers must be set to full duplex.
Consult the operating system documentation for instructions on how to determine and
change the NIC settings.
Note Using AUTOSENSE may cause network problems and performance issues.
Network load
There are two key considerations to monitor when you evaluate remote backup
performance:
The amount of network traffic
The amount of time that network traffic is high
Small bursts of high network traffic for short durations will have some negative impact on
the data throughput rate. However, if the network traffic remains consistently high for a
significant amount of time during the operation, the network component of the
NetBackup data transfer path will very likely be the bottleneck. Always try to schedule
backups during times when network traffic is low. If your network is heavily loaded, you
may wish to implement a secondary network which can be dedicated to backup and
restore traffic.
NetBackup media server network buffer size
The NetBackup media server has a tunable parameter that you can use to adjust the size
of the network communications buffer used to receive data from the network (a backup)
or write data to the network (a restore). This parameter specifies the value that is used to
set the network buffer size for backups and restores.
UNIX
The default value for this parameter is 320 32.
The default value for this parameter is derived from the NetBackup data buffer size (see
below for more information about the data buffer size) using the following formula:
For backup jobs: (
For restore jobs: (
For tape: because the default value for the NetBackup data buffer size is 65536 bytes, this
formula results in a default NetBackup network buffer size of 263168 bytes for backups
and 132096 bytes for restores.
For disk: because the default va lue for the NetBackup data buffer size is 262144 bytes, this
formula results in a default NetBackup network buffer size of 1049600 bytes for backups
and 525312 bytes for restores.
To set this parameter, crea te the following files:
UNIX
/usr/openv/netbackup/NET_BUFFER_SZ
/usr/openv/netbackup/NET_BUFFER_SZ_REST
Windows
install_path\NetBackup\NET_BUFFER_SZ
install_path\NetBackup\NET_BUFFER_SZ_REST
These files contain a single integer specifying the network buffer size in bytes. For
example, to use a network buffer size of 64 Kilobytes, the file would contain 65536. If the
files contain the integer 0 (zero), the default value for the network buffer size is used.
If the NET_BUFFER_SZ file exists, and the NET_BUFFER_SZ_REST file does not exist, the
contents of NET_BUFFER_SZ will specify the network buffer size for both backup and
restores.
If the NET_BUFFER_SZ_REST file exists, its contents will specify the network buffer size
for restores.
If both files exist, the NET_BUFFER_SZ file will specify the network buffer size for
backups, and the NET_BUFFER_SZ_REST file will specify the network buffer size for
restores.
Because local backup or restore jobs on the media server do not send data over the
network, this parameter has no effect on those operations. It is used only by the
NetBackup media server processes which read from or write to the network, specifically,
the bptm or bpdm processes. It is not used by any other NetBackup processes on a master
server, media server, or client.
This parameter is the counterpart on the media server to the Communications Buffer Size
parameter on the client, which is described below. The network buffer sizes are not
required to be the same on all of your NetBackup systems for NetBackup to function
properly; however, setting the Network Buffer Size parameter on the media server and the
Communications Buffer Size parameter on the client (see below) to the same value has
significantly improved the throughput of the network component of the NetBackup data
transfer path in some installations.
Similarly, the network buffer size does not have a direct relationship with the NetBackup
data buffer size (described under “Shared memory (number and size of data buffers)” on
page 96). They are separately tunable parameters. However, setting the network buffer
size to a substantially larger value than the data buffer has achieved the best performance
in many NetBackup installations.
Synthetic full backups on AIX NetBackup servers
If synthetic full backups on AIX NetBackup servers are running slowly, increase the
NET_BUFFER_SZ network buffer to 2 621 44 (256KB). To do this, create a file called
/usr/openv/netbackup/NET_BUFFER_SZ and change the default setting (32032) to
262144. This file is unformatted, and should contain only the size in bytes:
$ cat /usr/openv/netbackup/NET_BUFFER_SZ
262144
$
Changing this value can affect backup and restore operations on the media servers. Test
backups and restores to ensure that the change you make does not negatively impact
performance.
NetBackup client communications buffer size
The NetBackup client has a tunable parameter that you can use to adjust the size of the
network communications buffer used to write data to the network for backups.
This client parameter is the counterpart on the client to the Network Buffer Size parameter
on the media server, described above. As mentioned, the network buffer sizes are not
required to be the same on all of your NetBackup systems for NetBackup to function
properly. However, setting the Network Buffer Size parameter on the media server (see
above) and the Communications Buffer Size parameter on the client to the same value
achieves the best performance in some NetBackup installations.
To set the communications buffer size parameter (on UNIX clients)
Create the /usr/openv/netbackup/NET_BUFFER_SZ file.
As with the media server, it should contain a single integer specifying the
communications buffer size. Generally, performance is better when the value in the
NET_BUFFER_SZ file on the client matches the value in the NET_BUFFER_SZ file on the
media server.
Note The NET_BUFFER_SZ_REST file is not used on the client. The value in the
NET_BUFFER_SZ file is used for both backups and restores.
To set the communications buffer size parameter (on Windows clients)
1. From Host Properties in the NetBackup Administration Console, expand Clients and open the Client Properties > Windows Client > Client Settings dialog for the
Windows client on which the parameter is to be changed.
2. Enter the desired value in the Communications buffer field.
This parameter is specified in the number of kilobytes. The default value is 32. An
extra kilobyte is added internally for ba ckup operations. Therefore, the default
network buffer size for backups is 33792 bytes. In some NetBackup installations, this
default value is too small. Increasing the value to 128 improves performance in these
installations.
Because local backup jobs on the media server do not send data over the network, this
parameter has no effect on these local operations. This parameter is used by only the
NetBackup client processes which write to the network, specifically, the bpbkar32
process. It is not used by any other NetBackup for Windows processes on a master
server, media server, or client.
3. If you modify the NetBackup buffer settings, test the performance of restores with the new settings.
When a master or media server backs itself up, NetBackup uses shared memory to speed
up the backup. In this case, NetBackup uses shared memory rather than socket
communications to transport the data between processes. However, sometimes situations
may arise where it is not possible or desirable to use shared memory during a backup.
Touching the file NOSHM in the /usr/openv/netbackup (UNIX) directory or the
install_path\NetBackup (Windows) directory causes the client and server to use
socket communications rather than shared memory to interchange the backup data.
(Touching a file means changing the file’s modification and access times.)
The file name is NOSHM and should not contain any extension.
Each time a backup runs, NetBackup checks for the existence of this file, so no services
need to be stopped and started for it to take effect. One example of when it might be
necessary to use NOSHM is when the master or media server hosts another application
that uses a large amount of shared memory, for instance, 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 backups when it is applied to a system with a directly-attached storage unit.
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, such as a client that happens
to be a master or media server. A remote backup is a backup that passes the data across a
network connection from the client to a master or media server ’s storage unit.
A local backup normally has one or more bpbkar processes that read from the disk and
write into shared memory, and a bptm process that reads from shared memory and writes
to the tape. A remote backup has one or more bptm (child) processes that read from a
socket connection to bpbkar and write into shared memory, and a bptm (parent) process
that reads from shared memory and writes to the tape. NOSHM forces the remote backup
model even when the client and the media server are the same system.
For a local backu p 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 used by the bptm process to buffer data
being written to tape. bptm us es shared memory for any backup, local or otherwis e.
Using multiple interfaces
For a master or media server configured with more than one network interface,
distributing NetBackup traffic over all available network interfaces can improve
performance. This can be achieved by configuring a unique hostname for the server for
each network interface and setting up bp.conf entries for these hostnames.
For example, suppose the server is configured with three network interfaces. Each of the
network interfaces connects to one or more NetBackup clients. The following
configuration allows NetBackup to use all three network interfaces:
In the server ’s bp.conf file, add one entry for each network interface:
SERVER=server-neta
SERVER=server-netb
SERVER=server-netc
In ea ch client’s bp.conf, make the following entries:
SERVER=server-neta
SERVER=server-netb
SERVER=server-netc
It is okay for a client to have an entry for a server that is not currently on the same
network.
To improve NetBackup server performance, consider the following factors regarding the
data transfer path.
Shared memory (number and size of data buffers)
Parent/child delay values
Using NetBackup Wait and Delay counters
Fragment size and NetBackup restores
Other restore performance issues
Shared memory (number and size of data buffers)
The NetBackup media server uses shared memory to buffer data between the network
and the tape drive (or between the disk and the tape drive if the NetBackup media server
and client are the same system). The number and size of these shared data buffers can be
configured on the NetBackup media server.
The size and number of the tape buffers may be changed so that NetBackup optimizes its
use of shared memory. Changing the default buffer size may result in better throughput
for high-performance tape drives. These changes may also improve throughput for other
types of drives.
Buffer settings are for media servers only and should not be used on a pure master server
or client.
Note Restores use the same buffer size that was used to back up the images being
restored.
Default number of shared data buffers
The default number of shared data buffers for various NetBackup operations is shown in
the table below.
Default size of shared data buffers
The default size of shared data buffers for various NetBackup operations is shown in the
following table.
Default number of shared data buffers
Default size of shared data buffers
NetBackup Operation Size of Shared Data Buffers
UNIX Windows
Non-multiplexed backup 64K (tape), 256K (disk) 64K (tape), 256K (disk)
NetBackup Operation Size of Shared Data Buffers
Multiplexed backup 64K (tape), 256K (disk) 64K (tape), 256K (disk)
Restore, verify, or import same size as used for
same size as used for the
backup
the backup
Duplicate read side: same size as
read side: same size as used
for the backup;
write side: 64K (tape), 256K
(disk)
used for the backup;
write side: 64K (tape),
256K (disk)
On Windows, a single tape I/O operation is performed for each shared data buffer.
Therefore, this size must not exceed the maximum block size for the tape device or
operating system. For Windows systems, the maximum block size is generally 64K,
although in some cases customers are using a larger value successfully. For this reason, the
terms “tape block size” and “shared data buffer size” are synonymous in this context.
Amount of shared memory required by NetBackup
Use this formula to calculate the amount of shared memory required by NetBackup:
(number_data_buffers * size_data_buffers) * number_tape_drives * max_multiplexing_setting
For example, assume that the number of shared data buffers is 16, the size of the shared
data buffers is 64 Kilobytes, there are two tape drives, and the maximum multiplexing
setting is four. Following the formula above, the amount of shared memory required by
NetBackup is:
(16 * 65536) * 2 * 4 = 8 MB
Be careful when changing these settings (see the next caution).
Changing the number of shared data buffers
To change the number of shared data buffers, create the following file(s) on the media
server (note that the NUMBER_DATA_BUFFERS_RESTORE file is only needed for restore
from tape, not from disk):
UNIX
/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS
/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_RESTORE
These files contain a single integer specifying the number of shared data buffers
NetBackup will use. The integer represents the number of data buffers. For backups (in
the NUMBER_DATA_BUFFERS file), the integer’s value must be a power of 2.
If the NUMBER_DATA_BUFFERS file exists, its contents will be used to determine the
number of shared data buffers to be used for multiplexed and non-multiplexed backups,
as well as for restores from disk.
If the NUMBER_DATA_BUFFERS_RESTORE file exists, its contents will be used to
determine the number of shared data buffers to be used for multiplexed restores from
tape.
The NetBackup daemons do not have to be restarted for the new values to be used. Each
time a new job starts, bptm checks the configuration file and adjusts its behavior.
Changing the size of shared data buffers
Caution It is critical to perform both backup and restore testing if the shared data buffer
size is changed. If all NetBackup media servers are not running in the same
operating system environment, it is critical to test restores on each of the
NetBackup media servers that may be involved in a restore operation. For
example, if a UNIX NetBackup media server is used to write a backup to tape
with a shared data buffer (block size) of 256 Kilobytes, then it is possible that a
Windows NetBackup media server will not be able to read that tape. In general,
it is strongly recommended you test restore as well as backup operations, to
avoid the potential for data loss. See “Testing changes made to shared memory”
on page 102.
To change the size of the shared data buffers, create the following file on the media server:
UNIX
For tape
/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS
For disk
/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS_DISK
Windo ws
For tape
install_path\NetBackup\db\config\SIZE_DATA_BUFFERS
For disk
install_path\NetBackup\db\config\SIZE_DATA_BUFFERS_DISK
This file contains a single integer specifying the size of each shared data buffer in bytes.
The integer must be a multiple of 32 kilobytes (a multiple of 1024 is recommended); see
the table below for valid values. The integer represents the size of one tape or disk buffer
in bytes. For example, to use a shared data buffer size of 64 Kilobytes, the file would
contain the integer 65536.
The NetBackup daemons do not have to be restarted for the parameter values to be used.
Each time a new job starts, bptm checks the configuration file and adjusts its behavior.
Analyze the buffer usage by checking the bptm debug log before and after altering the
size of buffer parameters.
Kilobytes per Data Buffer SIZE_DATA_BUFFER Value
32
32768
64
65536
96
98304
128
131072
160
163840
192
196608
224
229376
256
262144
IMPORTANT: Because the data buffer size equals the tape I/O size, the value specified in
SIZE_DATA_BUFFERS must not exceed the maximum tape I/O size supported by the
tape drive or operating system. This is usually 256 or 128 Kilobytes. Check your operating
system and hardware documentation for the maximum values. Take into consideration
the total system resources and the entire network. The Maximum Transmission Unit
Absolute byte value to be entered in SIZE_DATA_BUFFERS
(MTU) for the LAN network may also have to be changed. NetBackup expects the value
for NET_BUFFER_SZ and SIZE_DATA_BUFFERS to be in bytes, so in order to use 32k,
use 3 276 8 (32 x 1024).
Note Some Windows tape devices are not able to write with block sizes higher than 65536
(64 Kilobytes). Backups created on a UNIX media server with
SIZE_DATA_BUFFERS set to more than 65536 cannot be read by some Windows
media servers. This means tha t the Windows media server would not be a ble to
import or restore any images from media that were written with
SIZE_DATA_BUFFERS greater than 65536.
Note The size of the shared data buffers used for a restore operation is determined by
the size of the shared data buffers in use at the time the backup was written.
This file is not used by restores.
Recommended shared memory settings
The SIZE_DATA_BUFFERS setting is typically increased to 256 KB and
NUMBER_DATA_BUFFERS to 16. To configure NetBackup to use 16 x 256 KB data
buffers, specify 262144 (2 56 x 1024) in SIZE_DATA_BUFFERS and 16 in
NUMBER_DATA_BUFFERS.
Note that increasing the size and number of the data buffers will use up more shared
memory, which is a limited system resource. The total amount of shared memory used for
each tape drive is:
(buffer_size * num_buffers) * drives * MPX
where MPX is the multiplexing factor. For two tape drives, each with an MPX of 4 and
with 16 buffers of 256k, the total shared memory usage would be:
(16 * 262144) * 2 * 4 = 32768 K (32 MB)
0 commenti:
Post a Comment