Intel 170 Servers User Manual
y
Allocate fractional CPUs wisely. If your sizing indicates two partitions need 0.7 and 0.4 CPUs, see if
there will be enough remaining capacity in one of the partitions with 0.6 and 0.4 or else 0.7 and 0.3
CPUs allocated. By adding fractional CPUs up to a "whole" processor, fewer physical processors
will be used. Design implies that some performance will be gained.
there will be enough remaining capacity in one of the partitions with 0.6 and 0.4 or else 0.7 and 0.3
CPUs allocated. By adding fractional CPUs up to a "whole" processor, fewer physical processors
will be used. Design implies that some performance will be gained.
y
Avoid shared processors on large partitions if possible. Since there is a penalty for having shared
processors (see later discussion), decide if this is really needed. On a 32 way machine, a whole
processor is only about 3 per cent of the configuration. On a 24 way, this is about 4 per cent. Though
we haven't measured this, the general penalty for invoking shared processors (often, five per cent)
means that rounding up to whole processors may actually gain performance on large machines.
processors (see later discussion), decide if this is really needed. On a 32 way machine, a whole
processor is only about 3 per cent of the configuration. On a 24 way, this is about 4 per cent. Though
we haven't measured this, the general penalty for invoking shared processors (often, five per cent)
means that rounding up to whole processors may actually gain performance on large machines.
V5R1 Additions
In V5R1, LPAR provides additional support that includes: dynamic movement of resources without a
system or partition reset, processor sharing, and creating a partition using Operations Navigator. For more
information on these enhancements, click on System Management at URL:
system or partition reset, processor sharing, and creating a partition using Operations Navigator. For more
information on these enhancements, click on System Management at URL:
With processor sharing, processors no longer have to be dedicated to logical partitions. Instead, a shared
processor pool can be defined which will facilitate sharing whole or partial processors among partitions.
There is an additional system overhead of approximately 5% (CPU processing) to use processor sharing.
processor pool can be defined which will facilitate sharing whole or partial processors among partitions.
There is an additional system overhead of approximately 5% (CPU processing) to use processor sharing.
y
Uniprocessor Shared Processors. You can now LPAR a single processor and allocate as little as 0.1
CPUs to a partition. This may be particularly useful for Linux (see Linux chapter).
CPUs to a partition. This may be particularly useful for Linux (see Linux chapter).
18.2 Considerations
This section provides some guidelines to be used when sizing partitions versus stand-alone systems. The
actual results measured on a partitioned system will vary greatly with the workloads used, relative sizes,
and how each partition is utilized. For information about CPW values, refer to Appendix D, “CPW, CIW
and MCU Values for iSeries”.
actual results measured on a partitioned system will vary greatly with the workloads used, relative sizes,
and how each partition is utilized. For information about CPW values, refer to Appendix D, “CPW, CIW
and MCU Values for iSeries”.
When comparing the performance of a standalone system against a single logical partition with similar
machine resources, do not expect them to have identical performance values as there is LPAR overhead
incurred in managing each partition. For example, consider the measurements we ran on a 4-way system
using the standard AS/400 Commercial Processing Workload (CPW) as shown in the chart below.
machine resources, do not expect them to have identical performance values as there is LPAR overhead
incurred in managing each partition. For example, consider the measurements we ran on a 4-way system
using the standard AS/400 Commercial Processing Workload (CPW) as shown in the chart below.
For the standalone 4-way system we used we measured a CPW value of 1950. We then partitioned the
standalone 4-way system into two 2-way partitions. When we added up the partitioned 2-way values as
shown below we got a total CPW value of 2044. This is a 5% increase from our measured standalone
4-way CPW value of 1950. I.e. (2044-1950)/1950 = 5 %. The reason for this increased capacity can be
attributed primarily to a reduction in the contention for operating system resources that exist on the
standalone 4-way system.
standalone 4-way system into two 2-way partitions. When we added up the partitioned 2-way values as
shown below we got a total CPW value of 2044. This is a 5% increase from our measured standalone
4-way CPW value of 1950. I.e. (2044-1950)/1950 = 5 %. The reason for this increased capacity can be
attributed primarily to a reduction in the contention for operating system resources that exist on the
standalone 4-way system.
Separately, when you compare the CPW values of a standalone 2-way system to one of the partitions (i.e.
one of the two 2-ways), you can get a feel for the LPAR overhead cost. Our test measurement showed a
capacity degradation of 3%. That is, two standalone 2-ways have a combined CPW value of 2100. The
total CPW values of two 2-ways running on a partitioned four way, as shown above, is 2044. I.e.
(2100-2044)/2044 = -3%.
one of the two 2-ways), you can get a feel for the LPAR overhead cost. Our test measurement showed a
capacity degradation of 3%. That is, two standalone 2-ways have a combined CPW value of 2100. The
total CPW values of two 2-ways running on a partitioned four way, as shown above, is 2044. I.e.
(2100-2044)/2044 = -3%.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 18 - LPAR
295