Veritas Volume Manager 5.0 Administrator's Guide (September 2006)
460 Performance monitoring and tuning
Tuning VxVM
Tuning VxVM
This section describes how to adjust the tunable parameters that control the system
resources used by VxVM. Depending on the system resources that are available,
adjustments may be required to the values of some tunable parameters to optimize
performance.
General tuning guidelines
VxVM is optimally tuned for most configurations ranging from small systems to larger
servers. In cases where tuning can be used to increase performance on larger systems at
the expense of a valuable resource (such as memory), VxVM is generally tuned to run on
the smallest supported configuration. Any tuning changes must be performed with care, as
they may adversely affect overall system performance or may even leave VxVM
unusable.
Various mechanisms exist for tuning VxVM. Many parameters can be tuned using the
System Administration Manager (SAM) or the
kctune utility. Other values can only be
tuned using the command line interface to VxVM.
Tuning guidelines for large systems
On smaller systems (with fewer than a hundred disk drives), tuning is unnecessary and
VxVM is capable of adopting reasonable defaults for all configuration parameters. On
larger systems, configurations can require additional control over the tuning of these
parameters, both for capacity and performance reasons.
Generally, only a few significant decisions must be made when setting up VxVM on a
large system. One is to decide on the size of the disk groups and the number of
configuration copies to maintain for each disk group. Another is to choose the size of the
private region for all the disks in a disk group.
Larger disk groups have the advantage of providing a larger free-space pool for the
vxassist(1M) command to select from, and also allow for the creation of larger
volumes. Smaller disk groups do not require as large a configuration database and so can
exist with smaller private regions. Very large disk groups can eventually exhaust the
private region size in the disk group with the result that no more configuration objects can
be added to that disk group. At that point, the configuration either has to be split into
multiple disk groups, or the private regions have to be enlarged. This involves re-
initializing each disk in the disk group (and can involve reconfiguring everything and
restoring from backup).
A general recommendation for users of disk array subsystems is to create a single disk
group for each array so the disk group can be physically moved as a unit between systems.