z/OS Paging analysis Velocity Software, Inc. Velocity Software, Inc. is recognized as a leader in the performance measurement of z/VM and Linux on z. The Velocity Performance Suite consist of a set of tools that enable installations running z/VM to manage Linux and z/VM performance. In addition, many components of server farms can be measured and analyzed. Performance data can be viewed real-time through the use of either 3270 or a browser. The CLOUD Implementation (zPRO) component is designed for full cloud PaaS implementation as well as to extend the capabilities of the z/VM sysprog (system programmer) to the browser world. This feature moves system management to the point-and-click crowd. Archived data and reports can be kept available of long term review and reporting usine zMAP. The zVPS, formally ESALPS, components consist of: zMON (formally ESAMON - real-time display of performance data), zTCP (formally ESATCP - SNMP data collection), zMAP (formally ESAMAP - historical reporting and archiving), zVWS (formally ESAWEB - z/VM based web server), zTUNE (a subscription service), zVIEW (formally SHOWCASE - web based viewing of performance data), zPRO (new to the quality line of Velocity Software Products). Velocity continues to work with other software vendors to ensure smooth interface with or from other products such as VM:Webgateway, CA-Webgateway, EnterpriseWeb, MXG, MICS. Velocity software remains the leader and inovator in the z/VM performance, Linux performance, Managing cloud computing arenas.
Home | Contact Us    
About Us | Products | FAQ | zVIEW Demo | zPRO Demo | Customer Area | Education | Linux Hints & Tips | Presentations | News | Industry and Events | Employment Opportunities

z/OS Paging Performance Analysis using zOSMON

System paging performance comes from the SMF75 record. This record is supported and part of zOSMON reporting. The ZOSPAGE report provides this information. It is likely users will want to set up operational alerts based on paging rates to ensure installations are aware of spikes in page rates. The following ZOSPAGE report shows one such spike.

Report: ZOSPAGE      Z/OS PAGE Detail Report  Velocity Software Corporate
Monitor initialized: 10/01/20 at 11:52:00 on Z15S
---------------------------------------------------------------------------
Time/    Volume Devc Page  <-----Page Slots------------>  ASM  
  SYSID  Serial Nmbr Type  Total  MaxU  MinU   Avg   Bad  Used  page  I/O
------   ------ ---- ----- ----- ----- ----- ----- ----- ----- ----- -----
11:59:00 - 12:00:00
    V24A Totals:           1025K  418K  418K  418K     0     1   7.9   3.5
         24ASPG 0246 PLPA   234K 16366 16366 16366     0     0     0     0
         24ACAT 0241 Commn  9719  5567  5567  5567     0     0   0.0   0.0
         24ASPG 0246 Local  781K  396K  396K  396K     0     1   7.8   3.5
---------------------------------------------------------------------------
12:00:00 - 12:01:01
    V24A Totals:           1025K  425K  418K  423K     0     5 158.9   9.3
         24ASPG 0246 PLPA   234K 16366 16366 16366     0     0   0.4   0.4
         24ACAT 0241 Commn  9719  5608  5568  5602     0     0   0.9   0.4
         24ASPG 0246 Local  781K  403K  396K  401K     0     5 157.6   8.5

The question then is what caused this spike - can it be related to a specific job, and if that is CICS, can it be related to a specific transaction or increase in load.

In looking at first the ZOSJCPU (Job CPU) report, specifically at the storage component, and then focusing on "totals". One can see additional storage requirements occur in this relatively static environment consistent with the spike in page rates seen above.

Report: ZOSJCPU      z/OS Jo1.1 10/09/20   Page   46
Monitor initialized: 10/01/2
----------------------------------------------------
SYSID <------JOB----------> > zip
      Name     JobID   Step   Real Max Priv Shrd  on
                        Nbr p Used Aux Stor Stor  CP
----  -------- -------- --- - =--- --- ---- ---- ---
11:52:00 - 11:53:00
V24A
      Totals              . 0  827 787  41K 1088 2.0
      Totals              . 0  849 805 185K 1088 1.0
      Totals              . 0  850 805 184K 1088 2.0
      Totals              . 0  850 805 184K 1088   0
      Totals              . 0  849 805 185K 1088 2.0
      Totals              . 0  849 806 184K 1088 1.0
      Totals              . 0  849 806 184K 1088 1.0
11:59:00 - 12:00:00
      Totals              . 0  849 806 185K 1088 2.0
12:00:00 - 12:01:01
      Totals              . 0  873 811 184K 1088 3.0
      Totals              . 0  849 811 184K 1088 2.0
      Totals              . 0  849 811 184K 1088 1.0

At the time of interest, there was an increase in page space used, as well as real storage requirements. The next question is which job(s) changed from one minute to the next.

Comparing jobs from one interval to the next allows us to determine what caused the spike. Eliminating all of the small jobs using less storage than 10MB, showing just the relevant jobs showed the following: 

Report: ZOSJCPU      z/OS Jo1.1 10/09/20   Page   46
Monitor initialized: 10/01/2
----------------------------------------------------
SYSID <------JOB----------> > zip
      Name     JobID   Step   Real Max Priv Shrd  on
                        Nbr p Used Aux Stor Stor  CP
----  -------- -------- --- - =--- --- ---- ---- ---
11:58:00 - 11:59:00
V24A
      Totals              . 0  849 806 184K 1088 1.0
      C24ASTND STC02421   1 0 36.5  12 2230    0   0
      IZUSVR1  STC00788   3 0  259 168  21K 64.0 1.0
      MQA1MSTR STC00805   1 0 46.9  46  316    0   0
      MQA2MSTR STC00806   1 0 47.0  44  412    0   0
      OMVS     OMVS       1 0 34.3  14 7200    0   0
      SMSPDSE  System     1 0 11.9  14 55.0    0   0
      ZFS      STC00756   1 0  385 490  593    0   0
----------------------------------------------------
11:59:00 - 12:00:00
V24A
      Totals              . 0  849 806 185K 1088 2.0
      C24ASTND STC02421   1 0 36.5  12 2230    0   0
      IZUSVR1  STC00788   3 0  259 168  22K 64.0 2.0
      MQA1MSTR STC00805   1 0 46.9  46  316    0   0
      MQA2MSTR STC00806   1 0 47.0  44  412    0   0
      OMVS     OMVS       1 0 34.3  14 7200    0   0
      SMSPDSE  System     1 0 11.9  14 55.0    0   0
      ZFS      STC00756   1 0  385 490  593    0   0
----------------------------------------------------
12:00:00 - 12:01:01
V24A
      Totals              . 0  873 811 184K 1088 3.0
      C24ASTND STC02421   1 0 36.5  12 2230    0   0
      IZUSVR1  STC00788   3 0  259 171  21K 64.0 2.0
      JVMJCL86 JOB02708   1 0 23.2   0 12.0    0 1.0 <--------
      MQA1MSTR STC00805   1 0 46.9  46  316    0   0
      MQA2MSTR STC00806   1 0 47.0  45  412    0   0
      OMVS     OMVS       1 0 34.3  14 7200    0   0
      SMSPDSE  System     1 0 11.9  14 55.0    0   0
      ZFS      STC00756   1 0  385 491  593    0   0

And at this point, we can see one job that on this system runs every 30 minutes and causes a spike.

The point of this analsys is to show how to identify spikes in storage utilization and paging.


See what our customers say

Performance Tuning Guide

Sign up to receive the Velocity Software z/VM Tuning Reference Guide

Have a Velocity Software Sales Account Exec contact me.

IBM Z Ecosystem

Test drive our products
zVPS demo

Follow Velocity Software on LinkedIn!