Consultor Eletrônico

Status: Verified

GOAL:

Can I stop excessive AppServer memory consumption by moving large pieces of R-code into a shared memory procedure library?

GOAL:

Will using a shared memory procedure library for a single program that all clients run persistently at application startup save any memory?

GOAL:

Does it make sense to use a shared memory procedure library for a single large piece of R-code?

FACT(s) (Environment):

Progress 10.x
All Supported Operating Systems

FIX:

Before deciding whether using a shared memory procedure library is appropriate for a single large piece of r-code it is important to understand how a shared memory procedure library is utilized as compared to a normal procedure library or reading r-code from disk files by reading the following in the documentation:

- OpenEdge Deployment: Managing ABL Applications, Chapter 6, Managing Procedure Libraries
- OpenEdge Deployment: Managing ABL Applications, Appendix B, R-code Features and Functions

Once you understand the OpenEdge R-code execution environment and how procedure libraries are managed you can use this information to determine if, in your specific scenario, using a shared memory procedure library will reduce your memory consumption.

In most cases, using a shared memory procedure library instead of a normal procedure library will provide some degree of benefit because for a normal procedure library we will try to load the entire internal directory of the procedure library into local memory. Depending on how many programs are stored in the procedure library the entire directory may not be able to be loaded into local memory. You can force this internal directory size to be restricted to 512 bytes by using the -plm startup parameter. When using a shared memory procedure library we do not load the internal directory into local memory as it can be accessed directly via shared memory.

In regards to the memory consumption of the large piece of R-code, using a shared memory procedure library will again provide some benefit over a normal procedure library since the different segments of the R-code can be accessed directly from the shared memory and do not have to be loaded into local memory. However, it is important to understand that R-code is broken into segments and not all segments need to be loaded into memory at once. For example, each internal procedure is contained in its own action segment and if an internal procedure is not invoked its action segment will never be loaded into local memory. What this means is that simply placing a large multi-megabyte piece of R-code into a shared memory procedure library does not necessarily correlate to a reduction in memory consumption for each AppServer agent.

In actuality, when you are seeing a high level of memory consumption on an AppServer you should start analyzing your configuration and application for the following to ensure that your configuration parameters are optimal and your application code does not have any memory leaks in it:

1) Check the -Bt startup parameter to ensure that it is set to a proper value which balances memory consumption with desired performance levels.

2) Check all startup parameters to ensure that their settings are appropriate. Specifically check the -mmax, -D, -reusableObjects and -tmpbsize parameters.

3) Verify that any persistent procedures which your application code loads are unloaded at the appropriate time.

4) Verify that any dynamic database objects (buffers, queries, datasets, etc) are properly cleaned up. You can use the SESSION:FIRST-* attributes to walk the different widget trees and dump out details about anything that is in memory so you can find these leaked objects and clean them up.

5) Verify that any memptr variables are properly cleaned up by using the set-size(somePointer) = 0 statement.

6) Verify that all XML objects (DOM and SAX) are cleaned up properly.

Overall it is far more likely that excessive memory consumption on the AppServer is caused by one or more of the above.