Heap fragmentation caused by .NET remoting (TcpServerSocket)

#11

Quote:

I believe that my thread 4 is the finalizer thread. (!threads says
(Finalizer) to the right) But the stack for thread 4 is empty. I have
experienzed before that the finalizer thread seems to be stopped. Could it
be
stopped here as well?

Yep 4 is the finalizer thread, the finalizer thread is stopped when you are
debugging, it's only activated by the GC.

What do you mean by that? Isn't the finalizer thread much like a normal
thread? Stopped during GC and running when not GC'ing? The objects to be
finalized are queued by the GC but not finalized during GC. There are 3000+
objects in the finalize queue, so I don't understand why the finalizer thread
isn't finalizing one of them or waiting for items in the queue. I only see an
empty call stack for thread 4.

Kind regards Søren

#12

Quote:

There are 3000+
objects in the finalize queue, so I don't understand why the finalizer thread
isn't finalizing one of them or waiting for items in the queue. I only see an
empty call stack for thread 4.

Ups, I got it wrong. Didn't read all of those little letters. !FinalizeQueue
returns a summery of all objects *registered* for finalization and those
ready to be finalized. In all of my dumps I have zero objects ready to be
finalized, so I guess my finalize queue is empty. The empty stack for thread
4 makes perfect sense then.

One interesting thing is that 99% of the finalizable objects live in gen2.
So if they do need to be finalized, they are waiting for a gen2 collection.

#13

Quote:

Willy wrote:
But
still there is something I don't get, 'why do some objects stay pinned for
minutes?', IMO they don't stay pinned but they are re-used repeatedly, and
they give you the impression they are pinned for this long period (could be
wrong though).

Søren wrote:
You are probably right that the buffers don't stay pinned for minutes as I
suggested. Atleast ten of them could stay around for a long time. But
System.IO.ByteBufferPool doesn't keep the same 10 buffer in the cache. A new
buffer is allocated if the cache is busy or empty - and any buffer can be
returned to the cache, including recently allocated ones. This means that the
precious old buffers way back in gen2 can get wasted. And I gues they do get
wasted in my case (You state that the buffers look young). Could this be the
root of my trouble? That the System.IO.ByteBufferPool only keep 10 buffers
around? It would be interesting to try with 100 buffers.

I change opinion back again. I've looked closer at the possibly pinned
byte[] I got from !dh -stat. 11 of them also appear in the 17 minutes older
dump and all of those have the same handle pinning them. First point: there
are more than 10 (ByteBufferPool size), so they cannot all be reused. Second
point: It seems very unlikely that the buffers should be reused and pinned
with the excact same handles.

!gcroot 3cf4eea0
HANDLE(Pinned):6c2e00:Root:0x3cf4eea0(System.Byte[]
HANDLE(Strong):6c3f88:Root:0x22000cc(System.Net.So ckets.OverlappedAsyncResult)->0x6008718(System.AsyncCallback)->0x60086b8(System.Runtime.Remoting.Channels.Tcp.Tc pServerSocketHandler)->0x3cf4eea0(System.Byte[])
17 minutes earlier:
!gcroot 3cf4eea0
HANDLE(Pinned):6c2e00:Root:0x3cf4eea0(System.Byte[]
HANDLE(Strong):6c3f88:Root:0x2214264(System.Net.So ckets.OverlappedAsyncResult)->0x6029768(System.AsyncCallback)->0x6029708(System.Runtime.Remoting.Channels.Tcp.Tc pServerSocketHandler)->0x3cf4eea0(System.Byte[])

My conclusion is that I have some buffers that stay pinned for a very long
time. What could cause this? Did the first mini dump cause the application to
miss some network traffic so that some sockets never gets an answer? If so,
is the application also sensitive to more common network disturbances?

So my new questions are:
- When should the socket buffers have been unpinned?
- Are the buffers ever unpinned?
- What could cause the very long pin durations?
- How can I se how long the buffers have been pinned?
- Is there a way to list all pin handles in WinDbg/sos.dll?
- Is there any way I can avoid the problem?

Any suggestions how I can address those questions? Reading code with
Reflector doesn't really give me the needed overview

Kind regards Søren

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

Heap fragmentation caused by .NET remoting (TcpServerSocket)

Dotnet Framework (CLR) microsoft.public.dotnet.framework.clr

Re: Heap fragmentation caused by .NET remoting (TcpServerSocket) - 10-05-2005 , 05:29 PM

Re: Heap fragmentation caused by .NET remoting (TcpServerSocket) - 10-06-2005 , 03:03 AM

Re: Heap fragmentation caused by .NET remoting (TcpServerSocket) - 10-06-2005 , 08:57 AM