I was finally able to get some load-testing today, and it looks like that
ActiveHandlerThreads setting will probably do some good.
I ran tests against two different DB's, one with a larger data-load, and one
with a smaller load.
The smaller data load, we never experienced any problems, and we never went
above 7 active threads, with 22 concurrent users.
With the larger data load, we experienced vast slow-down on the server, and
the active threads were much higher.
We brushed on 25 a couple of times, but it recovered enough to continue..
We then focused everyone on a specific area that had been causing problems
before.
Within seconds we managed to max it out, and cause the server to grind to a
halt.
java.lang.RuntimeException: Request timed out waiting for an available
thread to run.
You may want to consider increasing the number of active threads in the
thread pool.
at jrunx.scheduler.ThreadPool$Throttle.enter(ThreadPool.java:125)
at
jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:448
)
at
jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:29
4)
at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)
Started flashing over the console running JRUN, and the metrics were showing
a 25/39 threadcount w/18 sessions.
The users at this point were either frozen, or getting JRUN errors.
I left it, dying, and watched the threadcount, and it did slowly drop, and
then Zero out.
The console however, then littered itself with :
04/19 11:22:50 error
java.lang.OutOfMemoryError
I've attached the full thread dump, from the time when the users started to
get the JRUN errors.
Interestingly this time, while the CPU did max out, the memory usage on the
box wasn't that high.
TIA,
~ Jon
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
