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
--
-----------------------------------------------------------------
lu...@debian.org debian/rules
lu...@ximian.com Monkeys do it better
_______________________________________________
Mono-list maillist - Mono-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-list
