[Mono-list] Heap-Shot with no GUI.

[Paolo Molaro]

On 11/05/10 Esben Laursen wrote:
> I did a install of the complete Heap-Shot and libs. I can start the
> profiling okay and I can do a "kill -PROF <pid>" and get the output file,
> however my program stalls before it comes to the part where I suspect a
> leak (also happens if I do not do a kill -PROF). It uses quite a lot of
> processes and time to load all the different settings which is normal,
> but I can see once I start my analyzer threads it stops and nothing
> happens. If I run with no --profile option it works as it should..
> 
> Any ideas? Anyone?
> 
> 
> > If there are other ways to debug this problem please let me know.
> 
> Can it be that Heap-Shot is the _only_ memory profiling tool out there
> for mono? It does not seem that stable (had a shit load of issues getting
> the GUI stuff to work)

Heap-Shot has a number of issues, since its codebase has several
dependencies on unsafe behaviour, so we have been working on a better
implementation.

The new profiler is now in git and it is able to perform heapshots
when running with the sgen garbage collector.
You basically run your program with:

	mono-sgen --profile=log:heapshot yourprogram.exe

and then generate a report from the profile data with:

	mprof-report output.mlpd

To generate a heapshot roughtly every 5 seconds use:

	mono-sgen --profile=log:heapshot,hsmode=5000ms yourprogram.exe

More documentation is available here: http://www.mono-project.com/Profiler
or in the mprof-report manpage.
It should work on most linux systems and OSX, it's currently untested on
windows.

As an example, this is some of the output you can get (with mprof-report
--traces on the profile data for an asp.net app):

        Heap shot 5 at 14.518 secs: size: 43684432, object count: 562907, class count: 543
             Bytes      Count  Average Class name
          10506984      87373      120 System.Collections.Hashtable.Slot[] (bytes: +1939272, count: +16161)
                87346 references from: System.Collections.Hashtable
           8130304      87486       92 System.Int32[] (bytes: +1706912, count: +16164)
                87346 references from: System.Collections.Hashtable
                40 references from: System.Collections.Generic.Dictionary<System.String,System.Int32>
                30 references from: System.Globalization.NumberFormatInfo
           6846000      57050      120 System.Web.Caching.CacheItem (bytes: +1232880, count: +10274)
           4891432      87347       56 System.Collections.Hashtable (bytes: +904176, count: +16146)
                28526 references from: System.Web.HttpStaticObjectsCollection
                28525 references from: System.Threading.ReaderWriterLock
                28524 references from: System.Web.SessionState.SessionStateItemCollection
           1597344      28524       56 System.Web.SessionState.InProcSessionItem (bytes: +287672, count: +5137)
                28524 references from: System.Web.Caching.CacheItem
           1597344      28524       56 System.Web.SessionState.SessionStateItemCollection (bytes: +287616, count: +5136)
                28524 references from: System.Web.SessionState.InProcSessionItem

This heapshot was taken 14.518 seconds after application startup, at the
time there were 562907 objects in the heap, of 543 different types,
using about 43 MB of memory.

As the data inside parens shows, since the previous heapshot, a lot of
hash tables are kept around referenced mostly from
HttpStaticObjectsCollection, ReaderWriterLock and
SessionStateItemCollection objects.
Following the data, SessionStateItemCollection objects are kept alive by
InProcSessionItem which are themselves kept alive from CacheItem
objects. The issue here is that some cached objects are never expired
from the cache.

Hope this helps.
(Yes, someone is developing a GUI so the above data will be easier to
understand).

lupus

-- 
-----------------------------------------------------------------
lupus at debian.org                                     debian/rules
lupus at ximian.com                             Monkeys do it better