What is the -mmax memory pool ?The Maximum Memory (-mmax) client session parameter specifies the maximum amount of memory allocated for r-code segments, in kilobytes.
It is a soft limit, meaning that it will be exceeded if no alternative action is available. The maximum value is the total size of r-code or OS resource limits, whichever is lower
Progress dynamically allocates space for r-code segments in the execution buffer as needed. When memory allocation reaches the value specified by the -mmax value, Progress will start swapping out non-active segments to make room for new active procedures. If all r-code segments in memory are considered active and none can be swapped out, Progress will increase the -mmax value and then display the warning message:
"WARNING: -mmax exceeded. Automatically increasing from <old value> to <new value>. (5409)"
Segments that are considered active:
- Segments that are on the "call stack", which are persistent and
- Text segments associated with other active segments.
Remaining r-code segments are considered to be available to be swapped out if necessary.
Prior to OpenEdge 10.2B, the r-code segments that are least recently
loaded will be the first to be swapped out when needed.
From OpenEdge 10.2B onward, the r-code segments that are least recently
used will be the first to be swapped out when needed.
This change in the swapping logic leads to significantly fewer swap operations being performed in most situations, thus providing overall performance improvement.
If a procedure is run to completion and is not persistent, Progress will not redeem the memory for the r-code until it is needed.
The same procedures are often run over and over again, which is why keeping them in memory as non-active improves performance by avoiding reloading.
When will a low -mmax cause issues ?1. When the
5409 warning messages appear on a regular basis this may indicate two things:
a. If the value stabilizes, there is no immediate issue; just an indication that the application requires more resources than the current settings provide. In this case, increase the -mmax startup parameter to change the initial value in order to meet the application's requirements.
b. If the limit keeps increasing without stabilizing at some point, the number of active segments keeps increasing, which indicates a resource leak in the application code.
2. A too low -mmax setting may cause an I/O bottleneck on the client's temp-files even when no warnings are raised.
This in turn can lead to performance issues, typically seen when using large procedures or deeply nested procedure calls. The reason for this is that larger segments and/or a larger number of segments may fill up the memory quickly, but the segments will go non-active. Non-active segments will be swapped out before the soft-limit on -mmax is being raised, which results in r-code swapping relatively soon without warnings. In this case increasing the -mmax normally helps to reduce disk I/O activity required to swap segments.
How the segment swapping is handled depends on the configuration.1. If the r-code is stored as separate .r files, swapping will always go to a client temp-file:
2. If the r-code is stored in a
procedure library and the PROLIB Swap (-pls) startup parameter is not specified,
swapping will not go to the client temp-file. Instead, r-code segments will be re-loaded from the procedure library as needed. This typically improves performance as the procedure library will remain open and will give the same read performance, while write operations are eliminated.
3. If the r-code is stored in a
procedure library and the PROLIB Swap (
-pls) startup parameter is specified,
swapping will take place to the client temp-file. This is recommended if the library is stored on a remote file system, and the network overhead on re-reading the segments has a bigger performance impact than the swapping disk I/O.
4. If the r-code is stored in a
memory-mapped procedure library and the procedure library's
codepage is the
same as the
session codepage,
r-code segments are not loaded into the -mmax pool. Instead, r-code segments are loaded directly from the shared memory segments the library is mapped to. As the segments are never in the
-mmax pool, they can also never be swapped out.
5. In releases prior to OpenEdge 10.2B, a memory-mapped procedure library cannot be used in a session at all unless library and session codepages match. Starting with OpenEdge 10.2B, if a
memory-mapped procedure library has a
different codepage than the
session's codepage, the r-code text segments will be codepage-converted and after the conversion they will always be swapped to the rcd* temp-file as if the -pls parameter was specified. Other r-code segments will behave as per point 4 above.
Related startup parameters1. Use Statistics (
-y) and Segment Statistics (
-yd) startup parameters to see segment allocation and swapping information. The statistics provided are often useful to identify when a low -mmax causes a lot of swapping activity without raising warnings.
2. Use the
-noincrwarn client startup parameter to suppress the warning messages when the limit is exceeded. This is not recommended in development, test or pre-production environments as these errors do indicate these settings may need further application tuning are needed. Please refer to Article
"How to suppress warning messages (5407),(5408),(5409),(5410) from displaying on client screens" 3. Use the
-hardlimit startup parameter to prevent the -mmax value from being exceeded. When doing so, the process will terminate using an untrappable STOP condition when the limit is hit. This only recommended for diagnostic purposes and environments where resources are limited.
