HP-UX System Administrator's Guide: Logical Volume Management (5900-3028, March 2013)
by I/O in progress, a given request might have to wait in a queue of requests until an entry becomes
available.
Another performance consideration for mirrored logical volumes is the method of reconciling
inconsistencies between mirror copies after a system crash. Two methods of resynchronization are
available: Mirror Consistency Recovery (MCR) and none. Whether you use the MWC depends
on which aspect of system performance is more important to your environment, run time or recovery
time.
For example, a customer using mirroring on a database system might choose "none" for the
database logical volume because the database logging mechanism already provides consistency
recovery. The logical volume used for the log uses the MWC if quick recovery time was an issue,
or MCR if higher runtime performance is required. A database log is typically used by one process
and is sequentially accessed, which means it suffers little performance degradation using MWC
because the cache is hit most of the time.
Disk Spanning
For disk areas that see the most intensive use by multiple processes, HP recommends spreading
the data space for this disk area across as many physical volumes as possible.
Number of Volume Groups
The number of volume groups is directly related to the MWC issues. Because there is only one
MWC per volume group, disk space that is used for many small random write requests must be
kept in distinct volume groups if possible when the MWC is being used. This is the only performance
consideration that affects the decision regarding the number of volume groups.
Physical Volume Groups
This factor can be used to enforce the separation of different mirror copies across I/O channels.
You must define the physical volume groups. This factor increases the availability by decreasing
the single points of failure and provides faster I/O throughput because of less contention at the
hardware level.
For example, in a system with several disk devices on each card and several cards on each bus
converter, create physical volume groups so that all disks off of one bus converter are in one group
and all the disks on the other are in another group. This configuration ensures that all mirrors are
created with devices accessed through different I/O paths.
Snapshots and Performance
Logical volumes that have snapshots associated with them could experience an increase in latencies
associated with writes. This is also applicable for writes on (writable) snapshots themselves. The
increased latencies are seen only for writes that fall on regions (unshare units) that are shared with
a successor/predecessor. The reason for this increased latency is the data unsharing that has to
precede the actual writes on the original logical volume or a snapshot. Note that the increase in
latencies is reduced as data gets unshared between the original logical volume and its snapshots.
Performance is also dependent on the unshare unit size configured for the snapshots of a logical
volume. The supported values of the snapshot unshare unit are 512K, 1024K, 2048K, and 4096K.
While choosing the unshare unit size one has to consider the kind of application that will be writing
to the snapshots or the original logical volume, and also consider the tradeoff between performance
requirements and metadata space that will have to be provisioned on disk.
The larger the unit of unshare, the more will the latency be when data has to be unshared and the
lesser the metadata space needed on disk to track the sharing relationship between snapshots and
the original logical volume. If the application performs large and occasional writes, then it is
recommended that a larger unshare unit is used. If the writes are small and occasional, then a
smaller unshare unit is recommended. If the write pattern is going to be such that they are small
and sequential, then again a large unshare unit is recommended because after the first unshare,
30 Configuring LVM