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

4.6.1 Performance
maintained in a 2 GB IRLM address space. However V2.2 is not restricted to this 2 GB limit.
The new maximum number of locks is theoretically 100 million, around 16 times more than
V2.1, assuming that ECSA does not become a bottleneck sooner.
Locks no longer reside in ECSA. Therefore, the PC=NO parameter in the IRLM procedure is
no longer honored. PC=YES is always used. This also means that the MAXCSA parameter
no longer applies, as it was related to ECSA storage usage. You can still specify both PC=NO
and MAXCSA= for compatibility reasons, but they are ignored by IRLM. Note that the IRLM
parameters are positional, so you cannot remove them altogether.
The fact that IRLM locks no longer reside in ECSA (when you were using PC=NO in V7) also
means that a considerable amount of ECSA storage, which used to contain the IRLM locks, is
now freed up in V8, and can be used by other subsystems (such as WebSphere) and other
applications.
IRLM V2.2 has two additional parameters that can be specified in the IRLM startup
procedure. These parameters are:
► MLMT - Max storage for locks:
This specifies, in MB or GB, the maximum amount of private storage available above the 2
GB bar that the IRLM for this DB2 uses for its lock control block structures. The IRLM
address space procedure uses this parameter (which you specify on the IRLM startup
proc EXEC statement) to set the z/OS MEMLIMIT value for the address space. Ensure
that you set this value high enough so that IRLM does not reach the limit. Note that the
value you choose should take into account the amount of space for possible retained locks
as well. IRLM only gets storage as it needs it, so you can choose a large value without any
immediate effects. IRLM monitors the amount of private storage used for locks. If the
specified limit is reached, new lock requests are rejected unless they are “must complete”.
APAR PQ87611 allows you to dynamically change the amount of storage used for locks
above the bar by using the z/OS command:
MODIFY irlmproc,SET,PVT=nnnn
where nnnn can be specified in nnnnM (MB) or nnnnG (GB). A SET,PVT= command
causes the MEMLIMIT to be updated; never lower than the default 2 G, and never lower
than the amount of storage in use, plus the 10% of reserved space.
► PGPROT - Page protect:
Acceptable values are NO and YES (default). The page protect IRLM startup procedure
parameter specifies whether or not IRLM loads its modules that reside in common storage
into page-protected storage. YES indicates that modules located in common storage are
to be loaded into page-protected storage to prevent programs from overlaying the
instructions. We recommend YES because it requires no additional overhead after the
modules are loaded, and the protection can prevent code-overlay failures. NO indicates
that common storage modules are to be loaded into CSA or ECSA without first
page-protecting that memory.
Some large DB2 environments, for example, large SAP R/3® environments, should consider
a MEMLIMIT of 4 GB for their IRLM if the real storage is available.
Table 4-11 shows the CPU time consumed by IRLM while running the IRWW workload in a
two member data sharing environment. Each value in the IRLM CPU row of the table
represents a DB2 member. All tests were run using PC=YES, including the V7 test. Note that
IRLM request CPU time is not included in IRLM CPU. Instead it is included in accounting
class 2.
172 DB2 UDB for z/OS Version 8 Performance Topics