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 -- ----------------------------------------------------------------- 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