Xmanager MEMLIMIT and CUSH64 parameter usage.

Products

• Subsystem Analyzer for DB2 for z/OS
• Detector for DB2 for z/OS
• Database Management for DB2 for z/OS - Administration Suite
• Database Management for DB2 for z/OS - Performance Suite
• Database Management for DB2 for z/OS - Recovery Suite
• Database Management for DB2 for z/OS - SQL Performance Suite
• Database Management for DB2 for z/OS - Utilities Suite

Issue/Introduction

What are the purpose of MEMLIMIT and CUSH64 parameters within Db2 tools for z/OS Xmanager?

Resolution

MEMLIMIT is the  parameter that controls the amount of usable 64 bit storage above the 2Gb line to hold objects in memory.
As for the MEMLIMIT value specified, Detector(PDT) uses only the storage it needs to process all its required tasks.                                             

CUSH64 is the parameter  that controls or monitors Xmanager storage utilization and takes action if a limit set is reached.
This parameter does not affect the actual storage utilization under Xmanager. CUSH64 specifies a numeric pair of memory
object(64 bit storage) limits interpret in MB. The high value can be omitted, but if present, it must be greater than the low value.
If the amount of 64 bit storage used to hold memory objects plus the CUSH64(high) value exceeds the memory object limit,
a short on storage condition is signaled to the processors in the region.

Once Xmanager determines that the amount of available region storage falls below a safe limit during Detector data collection,
it will start issuing the following messages:      

PXM0371 XMANAGER REGION INUSE CLOSE TO REGION LIMIT EPVT or  PXM0371 XMANAGER REGION INUSE HAS REACHED CRITICAL THRESHOLD FOR EPVT         
PXM0372 XMANAGER REGION INUSE HAS REACHED SHORTAGE THRESHOLD FOR EPVT        
PXM0370 CA XMANAGER SHUTDOWN IN PROGRESS XMID XXXX                            

The above messages are an indication that the current MEMLIMIT is not enough.
Xmanager will initiates region shutdown and:

1. Detector and Subsystems Analyzer collections will terminate the current interval, making it shorter than the specified interval hour.

2. Detector and Subsystems Analyzer collections will externalize the data collected for that short interval to Detector/Subsystem Analyzer datastore as it normally does.  

When an interval starts, PDT and PSA allocates storage as it needs.  When interval ends and a new interval starts, PDT and PSA start collecting data for the new interval. 
In the meantime, it writes out the data collected on previous interval to the datastore if externalization is chosen and then free the storage used in last interval.
So the storage usage at interval end may look higher until the storage of previous interval is freed. There is no data loss.

 3. Xmanager will free up the storage and start a new interval.

 

Recommendations:

1. Amend your Xmanager procedure to implement MEMLIMIT and CUSH64 to protect the run off of auxiliary storage if you’re not using these parms.                                  

2. Increase the MEMLIMIT to higher value than your current value and monitor the situation.

3. Shorten the collection interval if MEMLIMIT needs more auxiliary storage than you can bear.

4. Evaluate the need to collect all table/index statistics for all dynamic SQL statement.  This is controlled by include/exclude collection profile
    with DTB(Y/N). Turning DTB to 'N' in the collection profile lessens the storage requirement.

5. Evaluate the need to collect all Dynamic SQL TEXT statistics