Async Sockets, pinned objects and .NET 2.0

[Guest]

Hi, I am migrating an application from .NET 1.1 to .NET 2.0. It is a network
application that use asynchronous sockets intensively (with more than 300
active connections on average)

With .NET 1.1 I had problems because the buffers used in the BeginReceive
and BeginSend calls were pinned and prevented the heap to be compacted by the
GC. I managed to solve this problem by allocating the buffers at the
application start up using a buffer pool.

Now, in the same application, compiled with .NET 2.0 the heap is heavily
fragmented. I can see with perfmon that the pinned objects counter is about 4
times the number of pending asynchronous calls (it was exactly equal in .Net
1.1), so it seems that .NET 2.0 pins 4 objects for each asynchronous socket
call instead of pinning only the buffer.

This make senseless the approach of using a buffer pool (I get the same
memory footprint in .NET 2.0 using the buffer pool or not using it). And the
improvements done in .NET 2.0 in managing pinned objects are not good enough,
so the situation became worse.

Am I wrong with this conclusion? If not, Is there any workaround for this?
or a way I can do that the asynchronous socket calls pins only the
sending/receiving buffer? What other objects is .NET 2.0 pinning in the asyn
socket calls?

Thanks

 

[Chris Mullins]

The behavior you're seeing doesn't match the behavior that I've seen. We've
done quite a bit of stress testing on an .Net 2.0 Async Sockets application
(and on .Net 1.1).

We've got the same basic approach you use - a buffer pool pre-allocated to
aviod heap fragmentation, heave use of async sockets, and lots of data in
and out. We're doing a much higher socket count that you are - we
consistantly have 10k+ sockets, and during stress testing many, many more
than that.

One of my co-workers wrote up the basic memory management issues in detail
at:
http://www.coversant.net/dotnetnuke/Coversant/Blogs/tabid/88/EntryID/9/Default.aspx

(although if you're already allocating buffers and such, you won't get much
out of it).

Given the overall very positive experience we've had with sockets since
moving to .Net 2.0, I would take a look through your application for other
stuff. Use one of the memory bebugging tools to try to figure out what's
pinned - perhaps it's not your sockets buffers?

 

[Guest]

Thanks for your response and thanks the article. The only one recomendation I
am not doing is to use a buffer pool also for the sending packets, but I was
not using it with .NET 1.1 and it worked well...

I do not know how to identify the pinned ojects, can someone help me on this?

I can see that with .NET 2.0 I have 4 more times pinned objects than the
same application had with .NET 1.1, and the pinned objects seems to be
clearly related to the number of active connections since they use to be 4
times the number of active connections. Can someone canfirm this?

Thanks