Feedback
 
Did this article resolve your question/issue?

   

Your feedback is appreciated.

Please tell us how we can make this article more useful. Please provide us a way to contact you, should we need clarification on the feedback provided or if you need further assistance.

Characters Remaining: 1025

 


Article

How to find a memory leak?

« Go Back

Information

 
Article Number000021724
EnvironmentProduct: Progress
Version: 9.x
Product: OpenEdge
Version: 10.x, 11.x
OS: UNIX
Other: RDBMS, AppServer, Client
Question/Problem Description
How to find a memory leak?
How to measure a memory leak of a given process?
Steps to Reproduce
Clarifying Information
Error Message
Defect/Enhancement Number
Cause
Resolution
When a memory leak under given circumstances is suspected, the following outlines some investigative techniques to add metrics to this supposition.
  1. At the startup of the Progress session, take a baseline measure how much free memory and free swap is available. Then run the program reproducible. You will notice that free memory/swap drops down a little and then stabilises which is expected. After the program has been running for a specified period of time (based on your observations suspecting a memory leak) if there really is a memory leak, then the free memory/swap will be less than that which you started with, in other words the memory has not been released.
It is best is to watch the free memory/swap after the program has been run 2 or 3 times. The machine needs to "stabilize" which implies that the program should not be creating new records, otherwise each run will be different from the next and the results will need to be weighted.

In most cases, the virtual size of a program should stabilize. If the virtual size of a process grows and grows over a relatively long period of time, this is one true indicator of a memory leak.
  1. Use the TOP utility (refer to man pages and OS documentation). Note the total amount of free memory at the “top”, it will fluctuate a bit when the program is started and then settle down around a value and stay there (assuming of course that this is the ONLY process running on the system). If after this initial 'wobble' on memory, memory starts dropping through time then, yes, we can suspect that there is a memory leak.
  1. Start the shared-memory client session with -yx parameter and include the SHOW-STATS to take samples (say) every 1000 iterations (again depending on your previous observations suspecting a memory-leak in the process):
DEFINE VARIABLE istat AS INTEGER NO-UNDO:
< .... existing code block(s) .... >
ASSIGN istat = istat + 1.
IF istat MODULO 1000 = 0 THEN DO:
SHOW-STATS.
END.

The resulting proc.mon and client.mon files created in the Progress working directory, will then need to be analysed for increase in memory requirements over time.
  1. A good approximation of memory used by the process itself is "RSS - SHARE" from the TOP utility. Refer to Article 000021734, How much memory is uniquely in use by a process? 
Send these results to Progress Technical Support, together with the reproducible, log files, environment and system kernel parameters for further analysis.
Workaround
Notes
Attachment 
Last Modified Date8/30/2019 1:41 PM