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

[Paolo Molaro]

On 11/19/10 Esben Laursen wrote:
> Allocation summary
>       Bytes      Count  Average Type name
>   582718568      98056     5942 System.Byte[]
>          557328000 bytes from:
>                  pam.ClientRun:ProcessCombinedModues 
> (System.Collections.Generic.IEnumerable`1<pam.CombinedModule>)
>                  pam.ClientRun:GetSshData (pam.ModuleOptions.SshOptions)
>                  pam.SshControl:SendAndReturnData (string,string,int,bool)
>                  pam.SshControl:GetData (string,int)
>                  (wrapper remoting-invoke-with-check) 
> SBSimpleSSH.TElSimpleSSHClient:ReceiveText ()
>                  SBSimpleSSH.TElSimpleSSHClient:ReceiveText ()
> 
> The way I read the info is that my "ClientRun.ProcessCombinedModules" 
> invokes the "ClientRun.GetSshData" that invokes 
> SshControl.SendAndReturnData and so on..

Yes.

> My pam.SshControl.GetData invokes TElSimpleSSHClient:ReceiveText many 
> times to check if there are data comming back. So as I understand it its 
> in the "SBSimpleSSH.TElSimpleSSHClient:ReceiveText" that does not clear 
> a Byte array..

As I said in the previous email (the part that you didn't quote in your
reply), you have an allocation summary and I suggested that to
solve your problem you need a heapshot run, because you're trying to use
the allocation data as if it was heapshot data.
Let me try to simplify:

1) the allocation summary will tell you how many objects of each type have
been allocated in the application lifetime and their total size (always
at the end of the application lifetime). If you use --traces you can see
which method call sequence lead to the allocations. As such, this data
can be used to answer questions like:
	*) how much memory did I allocate in the application lifetime?
	*) where am I allocating the objects of any given type?

2) the heapshot summary (which you can get with: mono
--profile=log:heapshot ...) will tell you how many objects are present and
how much memory they use at the time of each successive heap shot. With
the --traces option you can also see which object types are holding
references to objects of any other given type. As such this info can be
used to answer questions like:
	*) at the X point in the lifetime of the application how many
	objects of a given type are present in the heap?
	*) what other objects (or GC handles, or other roots) are
	keeping them alive?
	*) is the number and size of the objects of any given type
	increasing during the application lifetime?

> The reason I am a little puzled about this is that the 
> "ClientRun" class runs every 5 minutes (it has a timer), but just before 
> it starts it sets "SshControl=null" and then later it creates a new 
> instance, so even if the "ReveiveText" method did not clear the Byte 
> array then it should be destroyed by the GC right?
> 
> Or am I reading the output wrong?

See above, the allocation summary can only tell you that you have
allocated many arrays in the ReveiveText () method. If you want to know
what objects are keeping the byte arrays alive, you will have to
run the profiler in heapshot mode and you will get output like:

Heap shot 0 at 4.330 secs: size: 2247136, object count: 21160, class count: 543
 Bytes      Count  Average Class name
827064        122     6779 System.Byte[]
               43 references from: System.Collections.Hashtable.Slot[]
                8 references from: System.Net.Sockets.Socket.SocketAsyncResult
                6 references from: System.IO.FileStream

Which tells us, for example, that 43 of the 122 byte arrays are kept
alive by the Slot[] arrays in a hashtable. Similarly you could find
what objects are keeping references to the byte arrays in your app, or
you may find that at any given point, byte arrays are not significantly
using much memory, but that you have other objects that you keep alive
some way and never let go.

lupus

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