I am pretty sure that the threads never exit the Handle phase. Once a
thread is created it never dies. I agree that the overhead of managing the
thread pool could be an issue. This is why I don’t need many threads
waiting but have a need for many threads. The client will make connections
that stay persistent for the lifetime of the process. There are not many
threads in the blocking phase, but there are many in the Handling phase.
“Adam Mallory” <email@example.com> wrote in message
“Tim Bochenek” <> firstname.lastname@example.org> > wrote in
news:a74uic$q00$> email@example.com> :
The thread pool has a low water value of 10, high water value of 20,
increment of 5, and a maximum or 500. The thread pool is effectively
static after the server has started handling requests. A client
connects via TCP/IP and the connection is maintained. There is a
separate thread for each connection. The connections do not come and
go unless there is an error in the communication. In this case the
client (or server) would close the connection and the client would
retry. There are about 15 threads serving data to the client at 10
times per second while the other 330 are blocked on IPC channels
waiting for messages to come in and be forwarded to the client. I am
pretty sure that the problem lies in the scheduling of all these
threads. If I create a process with 15 threads, I get a usage of about
15%, and the usage increases a little more than linearly as the number
or idle threads are added. These are threads that are just blocked.
Is the number of threads going to affect the scheduling that
dramatically since they are all scheduled globally? Does the scheduler
punish the system that much for having so many threads?
Perhaps I’m mis-understanding, you have a thread pool w/ a low of 10, and
high of 20 and a max of 500? You could be paying the price that once
are threads waiting over the high mark, we start killing them off, and
you get another request and then new threads are created. This type of
oscillation could be causing the “cpu usage” where creation and
are occuring over and over.
Perhaps bringing the highwater or max in closer to each other (I doubt you
want 400+ threads waiting around, each thread does take up resources in
terms of stack, thread spec. info etc)
QNX Software Systems Ltd.
[ > firstname.lastname@example.org > ]
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> email@example.com