High number of Handles
-
Hi there. In my company, we have a windows service app that relies on multiple threads functionality to process many socket requests at a time, using the Socket events OnDataArrival to proccess the arriving data. Although the system is working properly, the server administrator is complaining that the app process is using a very high number of handles. That is, when you open the Windows Task Manager and check for the Handles column, the number is around 30000 handles for the process. I've checked some sources and a reasonable number of Handles for a single process is around 3000, and a 8000 is already a very high number. I'm way too over this. Do anyone has some good sources relating .net threads and events with the use of OS handles? I need some hints on how to low the number of hanldes for the process. I should probably re-do the app with good threading pratices (the implementation is very old), but I need a faster solution for the actual service.
Regards, Leonardo Muzzi
-
Hi there. In my company, we have a windows service app that relies on multiple threads functionality to process many socket requests at a time, using the Socket events OnDataArrival to proccess the arriving data. Although the system is working properly, the server administrator is complaining that the app process is using a very high number of handles. That is, when you open the Windows Task Manager and check for the Handles column, the number is around 30000 handles for the process. I've checked some sources and a reasonable number of Handles for a single process is around 3000, and a 8000 is already a very high number. I'm way too over this. Do anyone has some good sources relating .net threads and events with the use of OS handles? I need some hints on how to low the number of hanldes for the process. I should probably re-do the app with good threading pratices (the implementation is very old), but I need a faster solution for the actual service.
Regards, Leonardo Muzzi
Hi, I haven't done any mass socket stuff, however the way I understand .NET sockets you don't need explicit threads at all; a BeginConnect, BeginAccept, or BeginReceive is handled asynchronously, and the events get handled on some other thread, typically taken from the ThreadPool. So I expect you only need one (or a few?) handles per socket. :)
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
-
Hi there. In my company, we have a windows service app that relies on multiple threads functionality to process many socket requests at a time, using the Socket events OnDataArrival to proccess the arriving data. Although the system is working properly, the server administrator is complaining that the app process is using a very high number of handles. That is, when you open the Windows Task Manager and check for the Handles column, the number is around 30000 handles for the process. I've checked some sources and a reasonable number of Handles for a single process is around 3000, and a 8000 is already a very high number. I'm way too over this. Do anyone has some good sources relating .net threads and events with the use of OS handles? I need some hints on how to low the number of hanldes for the process. I should probably re-do the app with good threading pratices (the implementation is very old), but I need a faster solution for the actual service.
Regards, Leonardo Muzzi
You're probably not really using that many handles, but have a leak in your code somewhere where handles are not being released properly.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak Microsoft MVP Visual Developer - Visual Basic
2006, 2007, 2008
But no longer in 2009... -
Hi there. In my company, we have a windows service app that relies on multiple threads functionality to process many socket requests at a time, using the Socket events OnDataArrival to proccess the arriving data. Although the system is working properly, the server administrator is complaining that the app process is using a very high number of handles. That is, when you open the Windows Task Manager and check for the Handles column, the number is around 30000 handles for the process. I've checked some sources and a reasonable number of Handles for a single process is around 3000, and a 8000 is already a very high number. I'm way too over this. Do anyone has some good sources relating .net threads and events with the use of OS handles? I need some hints on how to low the number of hanldes for the process. I should probably re-do the app with good threading pratices (the implementation is very old), but I need a faster solution for the actual service.
Regards, Leonardo Muzzi
Leonardo Muzzi wrote:
around 30000 handles for the process
Thats too much. AFAIK, the handles count includes the file handles, threads, mutex, semaphore etc. Look at the application source and ensure the resources are properly released. No resource should live longer than expected. Get some memory profilers and analyze the object allocation and GC activities. Other way is to log the application activities and analyze the log. This will help you to understand which area it is spending more time and what resources are not getting released properly.
Leonardo Muzzi wrote:
windows service app that relies on multiple threads functionality to process many socket requests at a time,
How are you doing this? Each thread per request? If yes, consider using asynchronous methods provided in the socket class. Asynchronous methods makes it possible to write highly thread efficient applications. Here[^] is a decent MSDN article which takes the subject in detail. :)
Navaneeth How to use google | Ask smart questions
-
Hi there. In my company, we have a windows service app that relies on multiple threads functionality to process many socket requests at a time, using the Socket events OnDataArrival to proccess the arriving data. Although the system is working properly, the server administrator is complaining that the app process is using a very high number of handles. That is, when you open the Windows Task Manager and check for the Handles column, the number is around 30000 handles for the process. I've checked some sources and a reasonable number of Handles for a single process is around 3000, and a 8000 is already a very high number. I'm way too over this. Do anyone has some good sources relating .net threads and events with the use of OS handles? I need some hints on how to low the number of hanldes for the process. I should probably re-do the app with good threading pratices (the implementation is very old), but I need a faster solution for the actual service.
Regards, Leonardo Muzzi
It's most likely a leakage, I doubt you are really using all those handles. You may check for missing calls to
Dispose()and similar. Not only for sockets, since handles are used also for open files etc.2+2=5 for very large amounts of 2 (always loved that one hehe!)
-
Leonardo Muzzi wrote:
around 30000 handles for the process
Thats too much. AFAIK, the handles count includes the file handles, threads, mutex, semaphore etc. Look at the application source and ensure the resources are properly released. No resource should live longer than expected. Get some memory profilers and analyze the object allocation and GC activities. Other way is to log the application activities and analyze the log. This will help you to understand which area it is spending more time and what resources are not getting released properly.
Leonardo Muzzi wrote:
windows service app that relies on multiple threads functionality to process many socket requests at a time,
How are you doing this? Each thread per request? If yes, consider using asynchronous methods provided in the socket class. Asynchronous methods makes it possible to write highly thread efficient applications. Here[^] is a decent MSDN article which takes the subject in detail. :)
Navaneeth How to use google | Ask smart questions
The application don't open and close sockets all the time: in fact, it just open and keep them opened. I must use different sockets to send and receive data. I have one thread per "send" socket. The "send" sockects are awalys opened and send data indefinitely, as long as it arrives in his own queue. There are 2 to 10 sockets like this being used at the same time, so 2 to 10 threads always active sending whatever arrives on the queue (separate queues). The "receive" sockets (one for each "send" socket) works using the OnDataArrival event. I suppose they use thread pool threads to fire the event. Anyway, I agree that what I need is a complete code revision to avoid memory leaks and some multithreading review too. The sockets doesn't seen to be the real problem. For example, there are too many "controls" over the queues, using some could-be-avoided multithread. I'll work on that direction. Does anyone know if the Enterprise Library can have something to do with this? It has been used to log some data in a sql server database. Thanks everyone for the support.
Regards, Leonardo Muzzi
-
The application don't open and close sockets all the time: in fact, it just open and keep them opened. I must use different sockets to send and receive data. I have one thread per "send" socket. The "send" sockects are awalys opened and send data indefinitely, as long as it arrives in his own queue. There are 2 to 10 sockets like this being used at the same time, so 2 to 10 threads always active sending whatever arrives on the queue (separate queues). The "receive" sockets (one for each "send" socket) works using the OnDataArrival event. I suppose they use thread pool threads to fire the event. Anyway, I agree that what I need is a complete code revision to avoid memory leaks and some multithreading review too. The sockets doesn't seen to be the real problem. For example, there are too many "controls" over the queues, using some could-be-avoided multithread. I'll work on that direction. Does anyone know if the Enterprise Library can have something to do with this? It has been used to log some data in a sql server database. Thanks everyone for the support.
Regards, Leonardo Muzzi
Leonardo Muzzi wrote:
I must use different sockets to send and receive data.
Why don't you use the same socket for sending and receiving data? IMO, you only need one server socket and it should be able to handle the connection and send/receive. Avoid creating unnecessary threads. Prefer asynchronous methods over the synchronous one.
Leonardo Muzzi wrote:
Does anyone know if the Enterprise Library can have something to do with this?
Not sure. :)
Navaneeth How to use google | Ask smart questions
-
Leonardo Muzzi wrote:
I must use different sockets to send and receive data.
Why don't you use the same socket for sending and receiving data? IMO, you only need one server socket and it should be able to handle the connection and send/receive. Avoid creating unnecessary threads. Prefer asynchronous methods over the synchronous one.
Leonardo Muzzi wrote:
Does anyone know if the Enterprise Library can have something to do with this?
Not sure. :)
Navaneeth How to use google | Ask smart questions
'Cause they are really different sockets. Diferent ip/port combination, different connections. The legacy application that answers to these sockets on the other side works like this. And I believe this is better , 'cause this application can receive many requests at the same time. Otherwise, it would block the connection until it gets the answer. I use the OnDataArrival event to receive the data, that is, assyncronous to the sending function.
Regards, Leonardo Muzzi