Welcome to the new Gigaspaces XAP forum. To recover your account, please follow these instructions.

Ask Your Question

Perm Gen Class Unloading

I have run into a problem with Perm Gen space. My Perm Gen size is about 18M after I start my agent. When I deploy one of my processing units, it increases to 50M after the class definitions are loaded. I would expect this to drop back down to 18M after I undeploy my processing unit, but it does not.

I increased the size of my Perm Gen size, but after a period of time, we still reach the limit and run out of memory because classes are not being unloaded.

I am running and QA Environment where there will be lots of code changes, un-deploying, and re-deploying of pu's; but not bouncing of containers. Is it possible that the class definitions are not seen as being already loaded after I deploy my processing unit a second time because they are being loaded by a completely different class loaded and seen as a completely different class definition? If so, how do I get it to clean up?

I am using the CMS Garbage Collector have enabled garbage collection on the Perm Gen space, from what I can tell. We are using the following JVM ARGS, but I don't see any Class Unloading logs anywhere.

-XX:+TraceClassUnloading -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=60 -XX:+UseCMSInitiatingOccupancyOnly -XX:+ExplicitGCInvokesConcurrent -XX:+UseCompressedOops -XX:+TieredCompilation -XX:+AggressiveOpts -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps -Xloggc:${LOG_DIR}/${NIC_ADDR}_GC.log

Thanks, DJ

{quote}This thread was imported from the previous forum. For your reference, the original is [available here|http://forum.openspaces.org/thread.jspa?threadID=3721]{quote}

asked 2011-07-27 15:01:04 -0500

djclifford gravatar image

updated 2013-08-08 09:52:00 -0500

jaissefsfex gravatar image
edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted

Would calling the org.openspaces.admin.gsc.GridServiceContainer.restart() for all the running GSCs after the undeploy solves the problem ?

answered 2011-07-27 15:57:00 -0500

shay hassidim gravatar image
edit flag offensive delete link more


Wouldn't that cause fail-over for anything else running in that container? Is there anything less disruptive to the grid?

djclifford gravatar imagedjclifford ( 2011-07-27 16:08:28 -0500 )edit

This will restart everything you have within the container. I was assuming the container is empty with this suggestion. I would like to see if this clears the Perm Gen.

shay hassidim gravatar imageshay hassidim ( 2011-07-28 03:05:01 -0500 )edit

I deployed and undeployed my processing units a few times and the Perm Gen size increased each time. I then restarted the container manually through the GigaSpaces GUI. (is this the same as calling the restart you mentioned?)

Both my processing units came back up and the Perm Gen space was given back.

We do have processing units that depend on each other though; where deployment order matters On restart, I don't think there is any guarantee I can assure they come up in the order I would like every time.

Thanks, DJ

djclifford gravatar imagedjclifford ( 2011-07-28 14:10:03 -0500 )edit

I'm not sure what cause the Perm Gen issues, but this has been reported in the past. The fact that restarting the container clears it means the JVM already marked it as "garbage" but from some reason it was not cleared. Anyway, you have a workaround you can use now. Still you might want to isolate PUs from each other. Using Zones would be a simple option.

Another option would be to use the StandaloneProcessingUnitContainer with your unit tests. This will avoid the perm gem issues and will give you better control on the tests: http://www.gigaspaces.com/wiki/displa...

If you are looking for better deployment tool checkout this one: http://www.gigaspaces.com/wiki/displa...

You are right that once there are multiple PUs and you have a failure these will be provisioned back in a random order. We will have better support for this in future releases.

Restarting the container via the UI doing the same as the restart() API I suggested.


shay hassidim gravatar imageshay hassidim ( 2011-07-29 07:37:20 -0500 )edit

Sorry, I was probably unclear with my situation. We are starting our grid by calling the script that starts the agents, which starts the gsc's by itself. The only things we are changing are JVM parameters. I am not running any unit tests. Our live gsc's on the grid are the ones that have the perm gen problem.

Also, when I restart a container isn't it effectively killing the container, restarting a new one in a new JVM, and redeploying any currently running processing units? My container comes up with another PID.

Thanks, DJ

djclifford gravatar imagedjclifford ( 2011-08-01 11:13:22 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2011-07-27 15:01:04 -0500

Seen: 230 times

Last updated: Jul 27 '11