[Mono-devel-list] Memory management for long running processes (desc-heap profiler)

[Ben Maurer]

On Tue, 2005-03-29 at 20:55 +0100, Alex Chudnovsky wrote: 
> Ben Maurer wrote:
> 
> >It gives you an output of the largest stuff. Where did you get the 100+ mb from?
> >  
> >
> Thats what I was trying to find out ;) Well, application DOES take fair 
> amount of memory, on Windows too,
> however it seems to use much more on Linux. Say on Windows typical 
> memory usage is about 50-60, however
> on Linux it appears to be 100Mb Virt memory and 50-60 of non-share 
> memory + a few megs of shared RAM.

You want to look at the `RES' column. But even that lies.

the `Virt' one is just plain wrong. Ignore that column.

> While on topic, and I think I mentioned that, I don't understand why 
> Environment.WorkingSet is correct
> on Windows port of Mono but seems to be set to 0 on Linux?!?! Should I 
> submit it as a bug?

We just haven't done code for that. I guess you can file a Wishlist bug.

> Can memory be used by SQLite that I think consumes memory in unmanaged 
> fashion unseen by GC?

Yes, it could. There might be a leak there...

> >Can you try running with GC_PRINT_STATS=yes mono foo.exe?
> >  
> >
> I just did run it (nice trick) and it printed the following (taken from 
> end):
> 
> --------------------------------------------------------------------------------------
> Initiating full world-stop collection 36 after 21849912 allocd bytes
> --> Marking for collection 36 after 21849912 allocd bytes + 558888 
> wasted bytes
> Collection 35 finished ---> heapsize = 45903872 bytes
> World-stopped marking took 60 msecs
> Complete collection took 80 msecs
> Initiating full world-stop collection 37 after 14422584 allocd bytes
> --> Marking for collection 37 after 14422584 allocd bytes + 232952 
> wasted bytes
> Collection 36 finished ---> heapsize = 45903872 bytes
> World-stopped marking took 60 msecs
> Complete collection took 70 msecs
> --------------------------------------------------------------------------------------
> 
> Is this an indication that high memory usage happens outside of managed 
> by GC memory?
> 
> If thats the case then what's the best way to identify the leak then?

The issue could be fragmentation.

Does the heapsize = xxxxx bytes grow without bound (ie, does it leak?).
If not, than managed memory is *not* your issue.

-- Ben