Now if the interactive CPU is held to less than
4
% CPU (the knee), then the CPU available for the
System, Batch, and Client/Server work is
100% - the Interactive CPU used
.
If the interactive CPU is allowed to grow above the knee, say for example
9
% (or 41 CPW), then the CPU
percent remaining for the Batch and System is calculated using the formulas above:
X = (9 - 4) / (11 - 4) = .71
(percent into the overhead area)
EIU = 4 + (.71 * (100 - 4)) = 72%
CPW remaining for batch = 100 - 72 = 28%
Note that a swing of + or - 1% interactive
CPU yields a swing of effective interactive utilization
(EIU)
from 58% to 86%.
On earlier server models, the dynamics of the interactive workload beyond the knee is not as abrupt, but
because there is typically less relative interactive capacity the overhead can still cause inconsistency in
response times.
2.9 Server Dynamic Tuning (SDT)
Logic was added in V4R1 and is still in use today so customers could better control the impact of
interactive work on their client/server performance. Note that with the new Model 170 servers (features
2289, 2290, 2291, 2292, 2385, 2386 and 2388) this logic only affects the server when interactive
requirements exceed the published interactive capacity rating. For further details see the section,
Performance highlights of current model 170 servers
.
Through dynamic prioritization, all interactive jobs will be put lower in the priority queue, approximately
at the knee of the curve. Placing the interactive jobs at a lesser priority causes the interactive jobs to slow
down, and more processing power to be allocated to the client/server processing. As the interactive jobs
receive less processing time, their impact on client/server processing will be lessened. When the
interactive jobs are no longer impacting client/server jobs, their priority will dynamically be raised again.
The dynamic prioritization acts as a regulator which can help reduce the impact to client/server
processing when additional interactive workload is placed on the system. In most cases, this results in
better overall throughput when operating in a mixed client/server and interactive environment, but it can
cause a noticeable slowdown in interactive response.
To fully enable SDT, customers MUST use a non-interactive job run priority (RUNPTY parameter) value
of 35 or less (which raises the priority, closer to the default priority of 20 for interactive jobs).
Changing the existing non-interactive job’s run priority can be done either through the Change Job
(CHGJOB) command or by changing the RUNPTY value of the Class Description object used by the
non-interactive job. This includes IBM-supplied or application provided class descriptions.
Examples of IBM-supplied class descriptions with a run priority value higher than 35 include QBATCH
and QSNADS and QSYSCLS50. Customers should consider changing the RUNPTY value for
QBATCH and QSNADS class descriptions or changing subsystem routing entries to not use class
descriptions QBATCH, QSNADS, or QSYSCLS50.
IBM i 6.1 Performance Capabilities Reference - January/April/October 2008
©
Copyright IBM Corp. 2008
Chapter 2 - Server Performance Behavior
26
