Hello,
What is the best way to recycle threads (and/or increase the number
allotted threads) from the thread pool. I have c# chat service which
many users connect. I have implemented some better thread managment
because I was seeing tons of "Not enough threads in thread pool to
complete operation" and my application would hang. New code, see
below:
WaitCallback loginCallBack = new WaitCallback(PoolFunc);
ThreadPool.QueueUserWorkItem(loginCallBack, message);
//Method PollFunc
void PoolFunc(object state)
{
int workerThreads,completionPortThreads;
ThreadPool.GetAvailableThreads(out workerThreads,
out completionPortThreads);
Thread.Sleep(2000);
NameValueCollection nv = GetNVFromMessage((Message)state);
try
{
nv.Add("Worker Threads:", workerThreads.ToString());
nv.Add("Completion Port Threads:", completionPortThreads.ToString());
LogTheUserInMethod((Message)state);
}
catch(Exception ex)
{
appBlocks.ExceptionManager.Publish(ex, nv);
}
}
Now, this seems to have taken care of the enough threads error message
I was seeing, however normally when the Threads in the performance tab
of the task manager hit around 750 (which seems low), the application
bottlenecks and doesn't do anything.
So, my question is twofold: Can anyone verify the approach (more code
is available upon request) and shouldn't the GetAvailableThreads
recycle these, or am I missing something. Any help would be extremely
and greatly appreciated, I am tired of awaking every business day at
5:30 to restart the service (after that, the rest of the day is fine)
and this is driving me mad.
- Dan
Barry Kelly - 21 Jul 2006 15:03 GMT
> What is the best way to recycle threads (and/or increase the number
> allotted threads) from the thread pool. I have c# chat service which
> many users connect. I have implemented some better thread managment
> because I was seeing tons of "Not enough threads in thread pool to
> complete operation" and my application would hang.
Are you using asynchronous I/O (i.e. BeginRead / BeginReceive /
BeginSend / BeginWrite / BeginAccept etc.) to avoid blocking calls to
I/O routines? That is necessary to scale to large numbers of clients.
> Now, this seems to have taken care of the enough threads error message
> I was seeing, however normally when the Threads in the performance tab
> of the task manager hit around 750 (which seems low), the application
> bottlenecks and doesn't do anything.
750 is a frighteningly high number, to me! It either means that you've
got ~750 concurrent CPU-bound operations (on a chat server?) - or you're
not using asynchronous I/O when you should be.
-- Barry

Signature
http://barrkel.blogspot.com/
dkisting@dankisting.com - 21 Jul 2006 16:51 GMT
Well, first of all, thanks for the post. But the server is a shared
Web Server, has a different, legacy Chat Application on it, amongst
others. When I restart the services, it only gets it down to about 580
processes or so. However, I am open to suggestions. I am not
currently with the web service calls using asynchronous calls, but that
shouldn't be hard to implement. That would be the place, correct?
> > What is the best way to recycle threads (and/or increase the number
> > allotted threads) from the thread pool. I have c# chat service which
[quoted text clipped - 16 lines]
>
> -- Barry
Chris Mullins - 21 Jul 2006 18:20 GMT
> What is the best way to recycle threads (and/or increase the number
> allotted threads) from the thread pool.
[...]
> Now, this seems to have taken care of the enough threads error message
> I was seeing, however normally when the Threads in the performance tab
> of the task manager hit around 750 (which seems low), the application
> bottlenecks and doesn't do anything.
It sounds like you're using a 1 thread per socket approach, which is great
for a few sockets, but doesn't work very well for a large number of sockets.
750 threads is only "low" for an application if you have 32 or more
processor cores (and even then, it's certainly not low!). On a single or
dual prodcessor machine, it's catastrophic for your application performance.
For much more detail of the architectures available to you when building
socket applications, see:
http://makeashorterlink.com/?R2EE5246D
--
Chris Mullins
http://www.coversant.net/blogs/cmullins