|
Contents | Previous | Next
Performance Considerations
Depending on environment or workload,
some customers may wish to give special consideration
to these items.
Some of them have potential for
negative performance impact.
Specialty Engines: Getting It Right
With the z10 processor and z/VM 5.4, customers can now combine
many different engine types into a single partition. Further,
customers can create virtual configurations that mimic the
hardware's flexibility. Our Specialty
Engines Enhancements article describes the performance
attributes of this new support.
Depending on the environment, customers will want to keep in mind
certain traits of the new mixed-engine capabilities. In this
brief discussion we attempt to lay out some of the fine points.
One consideration is that virtual CPU type and the setting of
SET CPUAFFINITY can make a big difference in performance
and utilization of the system. Consider a partition with CPs
and IFLs, with Linux guests defined with virtual IFLs. If
SET CPUAFFINITY is off, the Control Program will not dispatch
those virtual IFLs on those real IFLs. The real IFLs will remain
idle and thus some processing
capacity of the partition will be lost.
Similarly, if SET CPUAFFINITY
is on, those virtual IFLs will be dispatched only on those
real IFLs. If enough real IFLs are not present to handle the
virtual IFL computational load, wait queues will form, even
though the partition's real CPs might be underutilized.
Consider also the case of the customer having combined two
partitions, one all-IFL and one all-CP, into one partition.
The all-IFL partition
was hosting Linux work, while the all-CP partition was hosting
z/OS guests. In the merged configuration, if the customer
fails to change the Linux guests' virtual CPU types to IFL,
z/VM will not dispatch those guests' virtual engines on the
real IFLs in the new partition. Here again, attention to
detail is required to make sure the partition performs according
to expectation.
CP share is another area where attention is required. Share
setting is per-virtual-CPU type. A guest with mixed virtual
engines will have a share setting for each type. In tinkering
with guests' shares, customers must be careful to adjust the
share for the intended VCPU type.
Finally, on certain machines, real specialty engines are faster
than real general-purpose CPs. Incorrectly setting CPUAFFINITY
or incorrectly defining guest virtual CPUs could result in
decreased throughput, even if the real engines in use are not
overcommitted.
The new z10 and z/VM mixed-engine support gives customers
opportunity to run diverse workloads in a single z10 partition.
To use the partition well, though, the customer must pay
careful attention to the configuration he creates, to ensure
his virtual environment is well matched to the partition's
hardware.
Virtual CPU Share Redistribution
In z/VM 5.4, the Control Program redistributes share for stopped
virtual CPUs to still-running ones. For example, if a virtual
four-way guest with relative share 200 is operating with two
stopped virtual CPUs, the two remaining running ones will compete
for real CPU as if they each had relative share 100.
IBM is aware that some customers do occasionally stop their
guests' virtual CPUs and compensate for the stopped engines
by issuing CP SET SHARE. Some customers even have automation
that does this.
In migrating to z/VM 5.4, such customers
will want to revisit their automation
and make adjustments as appropriate.
IBM has changed CP Monitor so that several records now include
records of the share changes CP makes automatically for stopped
virtual CPUs. Our performance management
article describes the changed records.
Linux Install from HMC
When running on a z10, z/VM 5.4 can offer the HMC DVD drive
as the source volume for a Linux installation. Both SUSE and
RedHat distributions support installing from the HMC DVD.
IBM built this support so that customers could install Linux into
a z/VM guest without having to acquire and set up an external LAN
server to contain the Linux distribution DVD.
Customers need to be aware that though this support is functional,
it does not perform as well as mounting the DVD on a conventional
LAN server. In informal measurements, and depending on which
distribution is being
installed, IBM found the installation can be
11 to 12 times slower when using the HMC DVD, compared to mounting
the DVD in an external LAN server. Installation times as long
as three hours were observed.
Customers wanting to use this function will want to apply the
PTF for APAR PK69228 before proceeding. This PTF, available
on the GA RSU,
does help
performance somewhat, especially for RedHat installations.
Crypto Changes
APAR VM64440 to z/VM 5.2 and z/VM 5.3
changes z/VM's polling interval for cryptographic hardware
to be in line with the speeds of modern cryptographic coprocessors.
This change is in the base for z/VM 5.4.
APAR VM64082 to z/VM 5.2 and 5.3 changes the behavior of the
MDC storage arbiter. Recall the arbiter's job is to determine
how to proportion storage between guest frames and MDC. This
APAR, rolled into the z/VM 5.4 base, is not on any z/VM 5.2
or 5.3 RSU.
In some environments, notably large storage environments, the
change helps prevent the arbiter from affording too much favor
to MDC. Another way to say this is that the change helps keep
the arbiter from over-biasing toward MDC.
In other environments, this change can cause the arbiter to
bias against MDC too heavily, in other words, not afford MDC
enough storage.
A customer can determine whether MDC is biased correctly by
examining the FCX103 STORAGE report and looking at the system's
MDC hit rate.
Another way to examine hit rate
is to look at the
FCX108 DEVICE report and check the "Avoid" I/O rate for
volumes holding minidisks of interest.
To see how much storage MDC is using,
the customer can check
FCX138 MDCACHE or
FCX178 MDCSTOR.
If MDC hit rates seem
insufficient or if MDC seems
otherwise unbalanced,
the customer
can use the SET MDC command
to establish manual settings for
MDC's lower storage bound,
upper storage bound,
or bias value.
Absent VM64082,
z/VM 5.2 and z/VM 5.3
also tended to retain excess
frames in MDC even though the system
was short on storage.
As well as changing the arbiter,
VM64082 changed MDC steal processing,
to help MDC give up storage
when the available lists were low.
On z/VM 5.2,
the VM64082 steal changes work correctly.
However,
on z/VM 5.3 and z/VM 5.4, the VM64082 change
fails to assess the available
frame lists correctly. Consequently, MDC,
incorrectly believing free storage is
heavily depleted, routinely dumps its frames
back onto the available lists, even though there's
plenty of storage available.
This increases system CPU time, diminishes MDC effectiveness,
and ultimately reduces application transaction rate.
The problem is exacerbated in
systems that tend to have large numbers of contiguous
free storage frames, while
systems that page
heavily are less likely to be affected by the defect.
A solution to this, for both z/VM 5.3 and z/VM 5.4,
is available in APAR VM64510.
DMU Monitor Records
The Dynamic Memory Upgrade enhancement
produces CP Monitor records that describe memory configuration
changes.
In particular, CP is supposed to emit
the Memory Configuration Change record (MRMTRMCC, D1 R21)
whenever it notices that
standby or reserved storage has changed.
Several different stimuli can cause CP to emit MRMTRMCC.
However, because of a defect, CP fails to emit
MRMTRMCC when an issued CP SET STORAGE command
changes the standby or reserved values.
APAR VM64483 corrects this.
VMRM Limitations
VM Resource Manager (VMRM)
attempts to manage CPU
access according to CPU velocity goals for groups of
virtual machines.
It does so by manipulating guests' CP SHARE settings
according to actual usage reported by CP Monitor.
Ever since the introduction of mixed-engine support in z/VM 5.3,
VMRM has been subject to incorrect operation in certain
mixed-engine environments.
In particular, VMRM has the following limitations
which can cause problems depending on the system configuration:
- VMRM adds up share values for all virtual processors in the
virtual machine, instead of adding the shares into buckets according
to virtual CPU type.
- VMRM does not account for CPU affinity as established by the
CP SET CPUAFFINITY command.
- VMRM does not account for stopped virtual CPUs.
Because of these limitations, IBM believes VMRM will work correctly
only if the following configuration constraints are observed:
- The z/VM partition must consist either entirely of real CPs
or real IFLs, and also,
- Each guest's virtual processors must either be
all virtual CPs or all virtual IFLs, and also,
- None of a guest's virtual CPUs can be stopped.
IBM understands the importance of VMRM in mixed-engine
environments such as those offered by the z10 and z/VM 5.4.
Work continues in this area.
Performance APARs
Since z/VM 5.3 GA, IBM has made available several PTFs to
improve z/VM's performance.
Remember to keep abreast of
performance APARs
to see if any apply to your environment.
Large VM Systems
This was first listed as a consideration
for z/VM 5.2 and is repeated here. Because of the CP storage
management improvements in z/VM 5.2 and z/VM 5.3, it becomes
practical to configure VM systems that use large amounts of real
storage. When that is done, however, we recommend a gradual, staged
approach with careful monitoring of system performance to guard against
the possibility of the system encountering other limiting factors.
With the exception of the potential PGMBK constraint, all of the
specific considerations listed for z/VM
5.2 continue to apply.
Contents | Previous | Next
|
