70 DB2 10 for Linux on System z Using z/VM v6.2, SSI Clusters and LGR
7.1 Processor sharing
In a clustered environment where DB2 guests are being relocated, using ncapped shared
virtual processors is a useful technique for dynamically, triangularly, and automatically
managing idle processor capacity to accommodate unpredictable workloads.
Usually CP assigns each virtual machine with at least one virtual processor. CP then
allocates processor time to a virtual machine based on its SHARE setting, and by default
assigns each virtual machine the same share of processor time.
A general guideline is to define as many virtual processors as needed (maximum processor
resources required), but do not exceed the number of real processors assigned to this LPAR.
Extra virtual processors just add to the overhead and potentially increase the software
multiprocessing factors. For example, if the LPAR has four IFLs, then do not allocate five
virtual processors to a single Linux guest machine. If a situation occurs where the Linux guest
uses 100% of the processors, that will adversely affect the entire LPAR.
However, in an LPAR with four IFLs, you can assign three virtual processors to one Linux
guest and two virtual processors to a second Linux guest, as well as another two virtual
processors to a third Linux guest. All requests for processor cycles will be managed by z/VM
according to the relative priorities of the Linux guests. A processor configuration best practice
is to maintain the ratio of four active virtual processors to one logical processor allocated to
the LPAR.
But if the guest system operates at greater than 90% utilization for sustained periods, then we
can dedicate a processor for the guest. The system operator can then use the DEDICATE
command to dedicate virtual processors to real processors.
7.2 Dynamic processor allocation - share settings
During a DB2 guest relocation, it is suggested to recalculate the z/VM share setting in the
target z/VM cluster before the actual guest relocation. Share setting allows you to control the
priority that system resources are assigned to a Linux guest. These resources can include
processors, real storage, and I/O capability. An absolute or a relative share can be specified.
Special care needs to be taken when virtual guests are with a relative share, where they
receive access to system resources that are in proportion with respect to other virtual
machines with relative shares.
7.2.1 Share setting scenario
As an example, consider that we have two z/VM clusters (ITSOSS1 and ITSOSS2) with two
allocated processors. In ITSOSS1 we have two DB2 Linux guests (ITSOLNX1 and
Note: System operators need to dedicate the processor to a virtual machine only if they
are sure that a virtual machine can make full use of the processor.
Important: When a virtual machine is relocated, its current share settings may or may not
be appropriate on the destination system. Some thought should be given to what this
user's share should be on the new system, and the settings changed using the SET
SHARE command if necessary.

Get DB2 10 for Linux on System z Using z/VM v6.2, Single System Image Clusters and Live Guest Relocation now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.