Jboss应用程序性能不佳

Question

I have an application running in Jboss 5.1 and its having performance issue every other week and we have to restart the application to bring it back to normal. The above graph is captured when application is running at peak hour's .I'm trying to understand is there a room for improvement from application perspective before looking at the other areas (like infrastructure and network)

Graph generated through jvisualvm which shows heap usage

Here is the heap size settings I have got for this application

JAVA_OPTS="${JAVA_OPTS} -Xms3072m -Xmx6144m -XX:PermSize=512m -XX:MaxPermSize=2048m -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Dsun.lang.ClassLoader.allowArraySyntax=true "
JAVA_OPTS="$JAVA_OPTS -verbose: gc -Xloggc:/test/log/gc.log -XX: +PrintGCDetails -XX:+PrintGCDateStamps"

1. Why, from graph, the application is using only 3G of memory even though I have given 6G as max memory?
2. Is my GC settings correct? I may have copied from a different server, how do I make sure I have right GC setting for this application?
3. Is GC happening too frequently, if I remove time interval from settings how would it determine when GC has to run?
4. I took heap dump last time when we had to restart application and loaded it in jvisualvm but I don't know what to look for in heap dump(I'm not a developer) Can someone tell what to look for in heap dump and how to improve it
5. Is there anything else we can do to improve application performance from what we see in the graph and GC settings

Answer 1

Here are your points answered to my best ability:

1. For the time being, your app is happy with 3GB of heap and does not need to increase it. Presumably it does so as it goes along, before failing every other week.
2. GC performance tuning is the answer. You need to monitor and adjust, only when you know, what you adjusting. Then measure, log. Rinse and repeat.
3. It will run GC when it needs to (when its Young Generation is running out of space). It measures many things and takes various settings into consideration to decide, when to GC. It will happen without any assistance, but you can tell it a bit more of the global picture, which GC is trying to establish in order to tune itself.
4. You can slice and dice it in many ways. This amount of information yield many views. You can look at which classes using most memory, which could indicate where the problem lies (I presume a memory leak or some other system resource like file handle not being freed). See here for basic use of VisualVM
5. You need to know, what causes the problem. Usually the best thing to do is fix the faulty app, rather than shifting the burden to GC. If you have a resource leak, it will hit you sooner or later anyway.