Performance on 601/WAS
CLM 502/tomcat -> 601/Liberty
Win 2012 12GB RAM (8GB used by CLM) -> (Win 2012 16GB RAM (10GB used by CLM)
I have some series performance issues on my test environment with 601 fixi 002.
Logging in can take up to 30 secs -> 1min
Sometimes, the machine will hang, and it will be like this and then "snap back" and work fine. The problem, there are only two people on it right now testing. Simple creating work items and querying...
601ifix002...
Win 2012 12GB RAM (8GB used by CLM) -> (Win 2012 16GB RAM (10GB used by CLM)
I have some series performance issues on my test environment with 601 fixi 002.
Logging in can take up to 30 secs -> 1min
Sometimes, the machine will hang, and it will be like this and then "snap back" and work fine. The problem, there are only two people on it right now testing. Simple creating work items and querying...
601ifix002...
Accepted answer
Having 2G for nursery is not that concerning when using 10G max size for heap.
You can probably boost it up to 3G but without examining the verbose gc its just shooting in the dark.
How it works is . in your case 10GB is allocated for heap and 4GB is allocated for the Native Memory usage for the JAVA heap , (this is due to the options used -Xcompressedrefs ) + some GB for Direct Bytes Buffers.
So potentially you are using all your Physical memory and leaving nothing for OS and other processes.
In this case maybe you are better off using less heap size. (8GB )
If it turns out to be the problem with Native memory and not the JAVA heap it self then as you can see treatment is different.
Try to see how the heap performance is using JAVA option -verbose:gc
set JAVA_OPTS=%JAVA_OPTS% -verbose:gc
set JAVA_OPTS=%JAVA_OPTS% -Xverbosegclog
Restart the server.
This will start generating the gc log verbosegc.xxx.xxx.xxx.log which you can check after server started showing a hang. Atleast you would know if the heap is the problem or Native memory is causing too many explicit GC calls. Also check the memory usage of the machine to see if system is paging.
Also look in the log of CCM , JTS , etc which are under same liberty profile to check what errors are getting reported.
They probably will give you some clue what is causing the periodic slow down. This would require a bit of searching on what those errors mean.
Try to pin point the location of the problem.
If above does not help i think its better to open a PMR with IBM support.
You can probably boost it up to 3G but without examining the verbose gc its just shooting in the dark.
How it works is . in your case 10GB is allocated for heap and 4GB is allocated for the Native Memory usage for the JAVA heap , (this is due to the options used -Xcompressedrefs ) + some GB for Direct Bytes Buffers.
So potentially you are using all your Physical memory and leaving nothing for OS and other processes.
In this case maybe you are better off using less heap size. (8GB )
If it turns out to be the problem with Native memory and not the JAVA heap it self then as you can see treatment is different.
Try to see how the heap performance is using JAVA option -verbose:gc
set JAVA_OPTS=%JAVA_OPTS% -verbose:gc
set JAVA_OPTS=%JAVA_OPTS% -Xverbosegclog
Restart the server.
This will start generating the gc log verbosegc.xxx.xxx.xxx.log which you can check after server started showing a hang. Atleast you would know if the heap is the problem or Native memory is causing too many explicit GC calls. Also check the memory usage of the machine to see if system is paging.
Also look in the log of CCM , JTS , etc which are under same liberty profile to check what errors are getting reported.
They probably will give you some clue what is causing the periodic slow down. This would require a bit of searching on what those errors mean.
Try to pin point the location of the problem.
If above does not help i think its better to open a PMR with IBM support.
2 other answers
I hope you didnt install all the new apps in 6.0.1 . If you did then this will consume more java heap than 5.0.2
And if you do not allocate enough heap you would see something like what you reported.
Which is sometimes the login takes long ( 30 secs ) or as a matter of fact any action on application you are working with seems to hang while like creating WI or running queries
The symptom is an example of Garbage collection trying to free up memory when there is a need for it and nothing is left. This Pauses the application for the duration of time until the Garbage collection is finished. If GC is happening too often then you would observe the hang periodic freezes. After a while the application will "snap back" and will start working OK.
This is just one thought , For over all picture you would need to examine memory usage of the server by enabling -verbose:gc or take JAVA cores of the JAVA process to determine if its specific application problem hosted on the JVM of Liberty profile.
And if you do not allocate enough heap you would see something like what you reported.
Which is sometimes the login takes long ( 30 secs ) or as a matter of fact any action on application you are working with seems to hang while like creating WI or running queries
The symptom is an example of Garbage collection trying to free up memory when there is a need for it and nothing is left. This Pauses the application for the duration of time until the Garbage collection is finished. If GC is happening too often then you would observe the hang periodic freezes. After a while the application will "snap back" and will start working OK.
This is just one thought , For over all picture you would need to examine memory usage of the server by enabling -verbose:gc or take JAVA cores of the JAVA process to determine if its specific application problem hosted on the JVM of Liberty profile.
