ps this is a CPU centric application,basicly,it is a nested loop to construct a big string
java uses only one cpu on the dual machine so if
it shows 50%; 1 cpu runs on 100%.
start a second java-vm/jboss
and it will use the other 50% of you dual machine.
If thats true LViz, it's quite bad news if we have no intention to run more than one JBoss instance on a multi processor machine.
If not supported in the JVM it must be a way of configuring the server
to use both processors (JVM doesn't have to know about it), or?
depends on your os and your vm.
from sun java hotspot performance faq..
My program isn't scaling with the number of processors.
Scaling problems could be a multitude of things. First, your application may not be written in a scalable manner (if you use a lot of synchronization, for one example, or if you have only one thread, as another). It may also be that you are utilizing OS system resources which are not scalable. Finally, if you have many threads, it may be that garbage collection is getting in the way. Garbage collection in HotSpot is single threaded (a concurrent and parallel garbage collector will be available in version 1.5) which means that your Java threads must be suspended for each one. First, make sure your application isn't doing its own garbage collection via a "System.gc()" explicit call. This used to be a popular style when generational garbage collectors didn't exist (the 1.x versions of Java at Sun) but should no longer be necessary. Next, turn on -verbose:gc to view and time the collections. This will help determine if garbage collection is the problem. If it is, check out the question on pause times above to help with garbage collection issues. See also Tuning Garbage Collection with the 1.3.1 Java Virtual Machine.
The threading model used by the VM may be a problem. The Solaris threading model uses a many to many mapping of Java threads to OS threads. In other words, a single Java thread may be mapped to different OS threads during its lifetime, and any given OS thread may have more than Java thread.
You can try reducing the variability by using -XX:+UseBoundThreads. This will map the Java thread to a particular Solaris LWP (this option is not available on Windows/Linux).
One can also attempt, if on Solaris 8, to use the alternate libthread in /usr/lib/lwp /usr/lib/lwp/libthread.so will switch to a one level thread model. This disallows user level scheduling, as only the kernel will schedule the thread. If the thread blocks on a mutex, the LWP will block in the kernel. In general if there is high lock contention then the standard libthread will work better than the alternate libthread as the alternate libthread's operations are heavier weight.