DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

Table 4-11 IRLM CPU - V2.1 vs. V2.2
DB2 V7 V8 V8 Delta for P1 %
(V8-V7) / V7
IRLM (PC=YES) 2.1 2.2 2.2
Lock Protocol n/a 1 2
Group ITR
(commits/sec)
IRLM CPU
msec/commit
We can make some judgements here to assess the impact on CPU the IRLM V2.2 has over
the IRLM V2.1. Keep in mind that IRLM V2.2 is now a 64-bit application and the locks are
managed above the 2 GB bar. These figures show only a modest 1.8% increase in CPU with
this workload. The IRLM is generally not a significant user of CPU compared with other DB2
address spaces such as the DBM1 address space. So, this slight increase is not really
considered significant.
Significant savings in the IRLM CPU can be seen in the third test, when Locking Protocol
Level 2 was used, compared with the first test under DB2 V8. This CPU savings can directly
be attributed to the Locking Protocol Level 2, which significantly reduces XES contention
resolution. Refer to Chapter 8, “Data sharing enhancements” on page 319 for a more detailed
discussion of the new locking protocol implemented in DB2 V8.
PC=NO vs. PC=YES
In the past, the IRLM PC parameter, an option on the IRLM startup procedure JCL,
determined where the IRLM maintains its locks. PC=NO instructs the IRLM to maintain its
lock structures in ECSA, which is governed by the MAXCSA parameter. PC=YES instructs
the IRLM to maintain its lock structures in the IRLM private region. PC=YES causes
cross-memory linkage PC constructs to be used between DB2 and the IRLM, rather than the
cheaper branch constructs.
In the past, PC=NO was the general recommendation for performance, and PC=NO is the
default in DB2 V7. However, Cross Memory calls have become less expensive and recent
enhancements in lock avoidance techniques have greatly reduced the advantage of using
PC=NO.
Prior to DB2 V8, PC=YES has been the recommendation for high availability. PC=YES helps
you avoid “out of storage” problems related to exhausting ECSA. It also allows you to
decrease the ECSA size, and thus increase the private region size. It also allows you to raise
lock escalation limits and max locks per user limit in DSNZPARM, reducing the frequency of
lock escalations.
For some workloads, going from PC=NO to PC=YES may increase the CPU cost of each
IRLM request by as much as 10%. This is because the number of instructions required to
process a lock increase by about 5%, and cross memory instructions are generally more
expensive to process than normal instructions. However if 2% of the overall CPU time is
consumed by the IRLM, the overall impact of having PC=YES is 0.2%, (10% * 2%), which is
probably not noticeable. So, even in DB2 V7, the availability benefits of moving from PC=NO
to PC=YES outweigh the very slight performance benefits of PC=NO in most cases.
In any event, the PC and MAXCSA parameters are no longer used in the IRLM V2.2.
However, you must still specify them in the IRLM JCL for compatibility reasons.
Delta for P2 %
(V8-V7) / V7
823.56 804.69 933.41 -2.29% +13.34%
0.330 0.371 0.335 0.379 0.014 0.014 +1.85% -96.01%
Chapter 4. DB2 subsystem performance 173