Kbase P77461: How to find a memory leak ?
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/11/2008 |
|
Status: Verified
GOAL:
How to find a memory leak ?
GOAL:
How to measure a memory leak of a given process ?
FACT(s) (Environment):
All Supported Operating Systems
UNIX
Progress/OpenEdge Product Family
FIX:
When a memory leak under given circumstances is suspected, the following outline 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 "stabilise" 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.
2.) 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.
3.) 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.
3.) Start the shared-memory client session with -yx parameter and include the SHOW-STATS to take samples (say) every 1000 itterations (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.
4.) A good approximation of memory used by the process itself is "RSS - SHARE" from the TOP utility (refer to Solution P77401).
Send these results to Progress Technical Support, together with the reproducable, log files, environment and system kernel parameters for further analysis.