[Mono-devel-list] Memory management for long running processes
bmaurer at ximian.com
Mon Mar 28 14:45:56 EST 2005
On Mon, 2005-03-28 at 17:36 +0100, Alex Chudnovsky wrote:
> I have started running app under Mono's profiler and the issue appears
> to be related
> to Mono's GC unwilling to release memory allocated for basic objects
> such as strings.
Are you using --profile? This one does *not* look at if the data is
live. The heap profiler, living in svn right now, does this. However,
right now, it doesn't work that nicely with long running apps.
One thing that helped the beagle team to track down issues was my
profiler which dumps a list of types every little bit. It is in the
heap-prof module, you just have to make install there and then run:
mono --profile=desc-heap my.exe
Note that these *only* work on a recent mono (1.1.5 is fine).
> I appreciate that I am way too short on details but I have just started
> these memory leaks and wanted to post this message in hope to get some
> from people who know Garbage Collector well as there is little on the
> Net about Mono's
> GC apart from some words along the lines that it is not particularly
> strong with long running
The Beagle people have had lots of luck with our profiler. They are able
tog et long running programs very easily.
> The question that I have right now is whether programmer can do anything
> to assist
> GC to release memory used by strings, chars and byte's. Would
> assigning null to types
> that are nullable help at all?
> I am specifically concerned about strings since my application deals
> with loads of those
> and many of them are unique so memory is used but it should be released
> once processing
> is done, and it does not seem to happen. I will post more details,
> hopefully with test cases.
Getting data from the profilers I mentioned above would be helpful. Are
you seeing a leak in RSS size (from `ps')? That is the ultimate measure,
If all else fails, we'd love to see your program and figure out what is
wrong with the runtime.
More information about the Mono-devel-list