Filter
Top Products
473Performance monitoring and tuning
Tuning 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.
Number of configuration copies for a disk group
Selection of the number of configuration copies for a disk group is based on a
trade-off between redundancy and performance. As a general rule, reducing the
number configuration copies in a disk group speeds up initial access of the disk
group, initial startup of the
vxconfigd daemon, and transactions performed
within the disk group. However, reducing the number of configuration copies
also increases the risk of complete loss of the configuration database, which
results in the loss of all objects in the database and of all data in the disk group.
The default policy for configuration copies in the disk group is to allocate a
configuration copy for each controller identified in the disk group, or for each
target that contains multiple addressable disks. This provides a sufficient
degree of redundancy, but can lead to a large number of configuration copies
under some circumstances. If this is the case, we recommended that you limit
the number of configuration copies to a maximum of 4. Distribute the copies
across separate controllers or targets to enhance the effectiveness of this
redundancy.