[Installation, Configuration & DEPLOYMENT] - Re: query regarding the thread pool size in JBoss
by PeterJ
It has been a while since I played with JMetere, but I recall that it has a mechanism to test EJBs directly, and not through a web page (ie, via http).
You are not, by any chance, using a web service to access the EJB? I assume you have JMeter accessing a servlet or JSP which in turn is accessing the EJB.
But my original assertion still holds:
anonymous wrote : More is not always better. The more threads you allocate, the more contention there will be for the CPU(s).
There is always a sweet spot when setting any pool size. Going either above or below it causes performance degradation. The key is finding the sweet spot, which usually involves repeatedly running the test using different pool sizes. Of course, you also have to determine if the pool size is what is causing the bottleneck - if the bottleneck is elsewhere in the system then no amount of pool size tweaking will help. If you don't know how to do this yourself, you will have to hire someone to do it.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137607#4137607
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137607
18 years, 3 months
[Performance Tuning] - Re: 100% CPU usage with lots of memory
by PeterJ
With those heap setting, the JVM will always do a full collection, which you noticed. The reason why: the JVM assumes the worst - that all objects in the young generation will survive the collection. Thus all 3GB of the young gen objects will survive, but according to your settings there is only 2GB available (5GB heap - 3GB young gen), thus a full colleciton is required.
I recommend setting the MaxNewSize to a much smaller value, such as 200MB-400MB. It looks like your collections are never freeing more than about 200MB anyway.
If I understand your app correctly, it allocates a lot of objects and then keeps them in memory. Those objects will, after a few collections, reside in the old generation. From that point on, the only objects in the young generation will be temporary objects which you want to have cleaned up with a minor collection.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137605#4137605
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137605
18 years, 3 months
[Performance Tuning] - 100% CPU usage with lots of memory
by DeanoUK
Hi all,
We've got an application that stores a large amount of data in-memory which is then used by a lot of users.
Subsequently we're seeing CPU usage go through the use, and every now and then hit 100% (on a quad core machine with 8GB of mem) which I believe is when the JVM tries to garbage collect. The web app can't be used until JBoss is killed and restarted.
We currently have these JVM opts:
JAVA_OPTS="$JAVA_OPTS -Xms5g -Xmx5g -XX:MaxNewSize=3g -XX:PermSize=512m -XX:MaxP
ermSize=1g -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterv
al=3600000 -Djava.awt.headless=true -d64 -verbose:gc"
Which may or may not be causing the problems - my knowledge of GC management is very limited.
We see something similar to this in the logs:
| [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor451]
| [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor24]
| [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor450]
| [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor458]
(lots more)
[Full GC 4077824K->4077824K(4660352K), 7.6307480 secs]
| [Full GC 4077824K->4077625K(4660352K), 10.7810720 secs]
| [Full GC 4077823K->4077823K(4660352K), 7.6245730 secs]
| [Full GC 4077823K->4077611K(4660352K), 10.8113030 secs]
(lots more)
Any help would be much appreciated.
JBoss 4.2.1GA
SuSE Enterprise 10 SP1
Java 1.6.0_05
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4137589#4137589
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4137589
18 years, 3 months