Waiting request threads in 6.0 SP2

Question

we have noticed that in some situations, over time, the number of available request threads will drop, and the number of
current requests will rise!
pretty normal stuff, but once in a while they do not return to the waiting request pool, and the the current request
never seems to go away.
naturally this could be explained by setting up pages which never return. we stayed always from that!
requests that never returned. we also managed to avoid that.
but still over time, some requests never seem to get answered, the request threads never get back to the pool, and
eventually the number of available threads declines, till there are none.
is there a reporting mechanism within iPlanet to help diagnose these situations? perhaps giving stackcrawls of all
current request threads from the kjs at any given time. one option of of course to use -Xrunhprof with the VM to catch
threads in contention under Solaris. but are there other possibilities?
iPlanet seems to have a dearth of internal reporting tools.

Answer 1

You didn't give the specs on the boxes but 300 threads is probably way too
high. Here's a good rule of thumb:
NT/1CPU = 14 free exec threads when idle (use ctrl-break to verify)
NT/2CPU = 28 free exec threads when idle
SolSparc/2CPU = 48 free exec threads when idle (use kill -3 to verify)
SolSparc/4CPU = 96 free exec threads when idle
Note that some exec threads get gobbled by WL itself so after setting the
value you need to figure out how many you actually have available. For
example, if you set it to 15 you may end up with only 10 which means your
expectation is 33% off reality.
Peace,
Cameron Purdy
Tangosol, Inc.
Clustering Weblogic? You're either using Coherence, or you should be!
Download a Tangosol Coherence eval today at http://www.tangosol.com/
"Kirk Everett" <[email protected]> wrote in message
news:[email protected]..
We are getting out-of-memory errors on solaris using 6.0 SP2. We are
seeing the heap size just grow and grow at a steady pace as the
application is stressed tested using load runner. The tests simulate
only about 30-60 users with a fairly light workload. We've run basically
the same tests on NT without the memory problems so I'm wondering if it
has anything to do with our env. We've basically trimed the script to
do just login/logout and the heap grows to over 600MB in about 2 hours.
We've poured over our login/logout code and can't find any places where
we are holding onto memory. Just before the process runs out of memory
we get a log of full gc messages that take about 30 seconds with no
significant change in the heap size. Their are 4 instances running with
a 1GB heap and 300 execute threads each (2 weblogic instances on a
box). Could the heap size/execute thread be causing problems? I think
the heap and execute thread size is a bit excessive given there are only
50 db connections. I'd like to hear anyone's opinion on this problem
and our settings. Thanks.
Kirk