With above paramters we faced the problem of OutOfMemory Error: Perm Gen. After searching we added " -XX:MaxPermSize=256m " to it but this will not solve the issue. It will just delay and sooner or later we can again hit the same problem. So we added few more parameters as below
Now here is my thought process with the problem at hand.
1. Lot of reflection usage means lots of class definitions are being loaded
2. Perm Gen is associated with storage of class/method definitions in old generation
3. Golden rule - let the JVM automatically set/change gc related params and algorithms than we specifying it. To do this give JVM the expected performance goals rather than configuring the algorithms by yourself
4. NewRatio=2 is suggested for client JVMs. For severs the recommended value is 8. Makes sense because your perm gen needs more space than new generations.
5. Give as much memory as possible, and specify performance(in terms of memory or throughput) goals using XX switch and let JVM roll. Such goal params are -XX:MaxGCPauseMillis and -XX:GCTimeRatio
Himanshu Rawat wrote:but this will not solve the issue. It will just delay and sooner or later we can again hit the same problem...
Have you considered looking at the design to see if you can reduce the amount of reflection? It seems that you've already worked out that it's your basic problem, and you may be able to speed up throughput as well (reflection is notoriously slow).
Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Joined: Nov 27, 2005
Thanks for the document. I will go through it .
I am thinking of changing the collector i.e. –XX:+UseConcMarkSweepGC to –XX:+UseParallelOldGC.
Perm Gen is associated with storage of class/method definitions in old generation
If am correct, Perm Gen is related to non heap area??
Joined: Nov 27, 2005
Design is THE main issue which can't be changed .
Yes, we analysed and diagnosed heap dumps through various tools and came to the conclusion i.e. "Reflection" issue and "String" literals. Heap dump was flooded with them!!
Earlier we had an option -Xnoclassgc which was preventing the unloading of classes but we now think that this option doesn't affect on Perm Gen area.
I am thinking of upgrading to "JDK 1.6 Update 29" with same options. May be it will solve at-least the high load issues if not Perm Gen
Perm Gen is non heap area alright, but is used to store class definitions. So, may be you could introduce intelligence in the system to periodically and explicitly unload unwanted class definitions from JVM if you can't stop using reflections. Also, try replacing string manipulations with StringBuffer/StringBuilder. Even such trivial changes might give you surprising results.
But then you can tell whether this is gc settings problem or it is actually a genuine memory issue for the current design right? Even if GC works at its best it may not help your problem. If that is the case you have to start tweaking reflection/string-manipulation code areas and parallelly pushing your higher-ups for design change, eh?
As Winston says, it makes sense to put your efforts in the right area.
256 is too small try 512.
I dont think class unloading is a wise because loading it again will cause lots of time?
try marking much of the method as final(utility methods) although not a good practise.Just for testing.
definietly logging in server side or client side is the cause of very poor perfromance.
try to figure out what you need to store in the memory and what you nee not to.