Socket BeginAccept Method Memory Leak?

Hi,

After copy and pasting the code from the MSDN sample "Asynchronous Server Socket Example" - http://msdn.microsoft.com/library/default.asp url=/library/en-us/cpguide/html/cpconnon-blockingserversocketexample.asp into a Windows Library project (DLL) for use in a server I'm writing, I'm finding that each request from my client application causes a growth in memory of 4-8KB in the server application. This doesn't seem to be reclaimed at all, it just continues to grow. Since I'm writing a server that must run unattended for long periods of time this will be a problem for me. After googling the problem I found a forum on dotnet247 where some other people were finding the same issue but no-one found a fix.

I'm using .NET 1.1 on Windows2000 but I've reproduced in .NET2.0 on WinXP.

Any help/suggestions would be much appreciated. Thanks in advance.

Colin

Answer this question

Socket BeginAccept Method Memory Leak?

jeffwu-2002

You need to make sure that the memory is eventually leveling off.
With GC, it is common to see memory growth and the memory presssure
increases, the GC will collect the memory.

Use the perfmon and plot private bytes of the process over an hour or two
KSLCam

That is the standard Async pattern in .Net. This should not cause you troubles. For additionals details on the improvements made to the GC in 2.0 see:

http://blogs.msdn.com/maoni/archive/2005/10/03/476750.aspx
using Drinks.Vodka.Martini
Thanks for the replies.

Gorm - I've actually replaced my asynchronous code with synchronous calls using background threads from the thread pool. I think memory use does plateau at some point but doesn't seem to go down. I can live with this situation.

I'll use perfmon to keep an eye on memory usage over time and see how it goes.

Thanks again

Colin
saurabhdotnet

Colmeister wrote:
I've actually replaced my asynchronous code with synchronous calls using background threads from the thread pool.

You should keep in mind that the threadpool is a limited resource and using synchronous methods on the threadpool could potentially cause the threadpool threads to block for long periods of time. This could cause you problems down the road if you end up using other APIs that also use the Threadpool. Just thought you should keep this in mind when designing your app.
VishalOnline

Hello.

> Mike Flasko:

> http://blogs.msdn.com/maoni/archive/2005/10/03/476750.aspx

Thank you.
This looks really really nice. Certainly takes care of my memory (performance-) concerns.

Would you comment on the IOCompletion ports and (what I expect must be) switches between kernel-mode and .NET awareness
If I have understand IOCompletion ports correctly, it involves to leave processing the kernel at the time the request is ready, if you (when the request is ready) jump into the managed world, will not the point of doing completion port be eaten up by the switch
rnv

Hi.

I think You should use some kind of thread collection for this. There are two good reasons for this (I can think of).

2) You have control over how many threads run at any time. It is not true that the more threads, the better performance.
1) You create the thread objects up front, so that when you have the heaviest load, you don't use all your resources creating thread objects.
Mike408
I disagree with the suggestion that you should use your own thread pool and do sync operations. Async is the best mechanism since it uses the IOCompletion ports and is scalable. I would like to know if the memory leak is showing up over time
comsolver

Absolutely not.

The point of IO Completion ports is really to reduce the number of threads requried to process multiple client connections. IO Completion ports are heavily used by any scalable app .NET or C++

For a best intro to IO COmpletion ports please see the WINSOCK book by Anthony Jones
pbd
Hello.
> "I disagree with the suggestion that you should use your own thread pool and do sync operations. Async is the best mechanism since it uses the IOCompletion ports and is scalable."

I can only agree, I think. IOCompletion ports sounds nice. Thread-wise. I don't understand switches between threads in managed code and the kernel. It is complex to me.

Would you comment on the perf (or scalabillity) of HttpListener (possibly with BeginGetContext()), compared

I am bothered by the sample's "new AsyncCallback(AcceptCallback)" and "new StateObject()" and the "new AsyncCallback(ReadCallback)" for each incoming req, but can't really back it up. Just looks like it will fragment the heap a bit. Sorry if I am ignorant.

I hope to get a feel of how these things works, since I will port a server from dll-api soon.

Thank you.
sansliguy

Generally, the GC will collect only as often as necessary. Does your application fail due to memory constriants As Durga notes below, please ensure the GC does not kick in and level off the memory usage.

Note, if you have many objects getting into gen 2, the GC will only collect when it is absolutely necessary for performance reasons.
Socket BeginAccept Method Memory Leak?

Answer this question