2. PERFORMANCE REPORTING ANALYSIS › 2.7 Graphic Analysis › 2.7.5 Paging Graphs › 2.7.5.3 Demand Page Rates by Perf Group/Svc Class

2.7.5.3 Demand Page Rates by Perf Group/Svc Class

GRAPHIC RESULTS

This graphic analysis provides a stacked vertical bar chart
of demand page rates separated by performance group or
service class.  Each group or class for which there is
data is shown as a separate segment on each bar.

ANALYSIS GUIDELINES

If demand paging exists, this chart will show which
performance groups or service classes are experiencing the
page faults.

When trying to manage demand paging effectively, you should
understand what workloads are experiencing it.  For
MVS systems not yet operating in "goal mode," providing
detail by performance group is only effective if workload
granularity has been established through two members in the
MVS system parameter library, SYS1.PARMLIB.  The first of
these, IEAIPSxx, the Installation Performance Specifications
member, contains the specifications defining to the System
Resource Manager of MVS how it is to distribute resources to
the various performance groups.  The second control member,
IEAICSxx, the Installation Control Specifications member, is
used by MVS to select the performance group for any
particular job, TSO user, started task, or APPC/MVS
transaction.  Having multiple applications running in the
same performance group restricts your capability to
distinctly analyze and manage such work.

Similar considerations come into play for MVS environments
operating in "goal mode" as introduced in MVS/ESA SP 5.1.
Here, the workload granularity must be established through
the use of service definitions via the Workload Manager
application.  Such definitions delineate both service
classes, controlling actual resource distribution to
different types of work, as well as "report service classes,"
which can be thought of as similar to the report performance
groups defined in IEAICSxx.

Additional information can be obtained by looking at paging
response times.  The I/O response time multiplied by the
number of page faults per second per workload type shows the
impact this paging is having on each workload type.  Dividing
this number by the average MVS multiprogramming level for a
workload would give you an estimate of the impact that an
individual user or job would experience.

Workloads that offer transaction reporting can provide
additional insight into the impact of paging, particularly
slow paging, upon these workloads.  The portion of the
transaction response time caused by paging could be estimated
by calculating the number of demand pages per transaction and
multiplying the result by the paging response time.

You should understand the behavior of the work in a
performance group or service class when demand paging occurs.
With a workload like TSO, which places each user in a unique
address space, when one user suffers a page fault, the
remaining users continue processing, since MVS is managing
their address spaces independently.  In contrast, when a
transaction processing address space, like CICS, experiences
a page fault, the impact of MVS halting activity in the
address space until the page fault is resolved can be much
greater, since the entire MVS task in the CICS address space
will go dormant until the page fault is resolved.  This has
the potential for halting all users that CICS is
multitasking at that moment.  Only I/O activity in progress
for active users will continue.

The detailed behavior of the paging subsystem can be further
analyzed using the Auxiliary Storage Management analysis
reports described in Section 2.2.