zOS memory management of large consumers can be challenging. In recent conversions I noticed that several Sysprogs were not aware of using z/OS Memory pools (MEMPOOL).
When z/OS introduce Apache SPARK support there was a concern that its typically large memory footprint could impact the system. Application programs may end up using more real memory then they had told the Sysprog that they would use. Large zCX (Container Extensions) guests have a similar concern. A sudden large demand of real memory may result in the system swapping out critical users in order to protect the system.
Keeping the data closer to where the action is a popular and an easy way to increase performance. As more large memory exploitation is becoming common place i.e. in storage database systems, Apache Spark™ working memory, very large DB2, MQ, VSAM RLS, buffer pools, etc., it makes managing memory usage more challenging.
As real memory and auxiliary storage are not infinite, z/OS has various virtual memory management controls:
Region (24/31 bit or below/above the “line” storage) limits.
MEMLIMIT (64 bit above the bar storage) limit. Both REGION and MEMLIMIT can be specified on JCL (memlimit, region, etc. keywords) and the current SMFPRMxx parmlib member. OMVS has its own means of setting a MEMLIMIT processes. Best practice is to set the limits as needed.
The SYSEVENT STGTEST API, can be used by virtual storage consumers to determine how much storage could be used before impacting the system or reaching their MEMPOOL limit.
To prevent paging from impacting others in a negative way, WLM Resource Group MEMLIMIT or MEMPOOLs provides an easy means of limiting the amount of real storage that a set of address spaces can use at any given time. For example, a Sysprog can control the amount of real memory that the application group said it was going to use for their application. The system enforces the limit by paging pages of the members of the MEMORY pool to auxiliary storage when they approach their limit. Those who don’t normally page and use MEMPOOls should ensure their auxiliary storage capacity is adequate.
Keep WLM Resource Group Memory Pools in mind when deploying large real memory consumers on your system. More information on memory pools can be found here:
https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.4.0/com.ibm.zos.v2r4.ieae100/mempools.htm