smartfoxserver.com

Sorry, it's another PermGen thread, I've read all the other threads regarding this but with no luck:

We're having an issue in which after a couple of days, of ~150-250 concurrent users and ~10,000 games, am running into the permgen out of space error. Our vmoptions include the following

-XX:MaxPermSize=256m
-XX:+CMSClassUnloadingEnabled
-XX:+CMSPermGenSweepingEnabled

and using visualvm I can see over the couple of days the permgen very low then gradually increasing, until it hits the top. A heap dump near the time of full permgen seems to suggest some classloaders are not being cleared as there are 1,628 of them which appear to linked with our Game extension. I'm not using any third party libraries and am definitely calling the super.destroy and clearing all the handlers etc. Is there any further info in the dump to figure out why there are so amny classloaders or anything else I can check?

Thanks

Richard

Hi Richard,
a good way to avoid this problem is to deploy the Room Extension to the extensions/__lib__/ folder. This will ensure that the classes will not by loaded by separated class loaders, and avoid the PermGen issues.

Have you considered this option?

I'm not using any third party libraries and am definitely calling the super.destroy and clearing all the handlers etc. Is there any further info in the dump to figure out why there are so amny classloaders or anything else I can check?

Normally these issues are generated by a memory leak. There could be anywhere a reference (maybe to the Room) which doesn't allow the whole tree of objects to be released, including the class loader.

It's difficult to say what it could be without an in-depth analysis. Normally you would need a profiler to dig into the heap and find out what is holding those class loaders. If you can reproduce the problem in your test environment then you can go ahead and inspect the heap. Otherwise I would recommend the __lib__ folder solution.

Ok, thanks, I will try the __lib__ approach, I just thought the correct way to do the extensions was in the folder as it won't affect the other extensions or require a restart.

Out of interest (and desire to learn more about Java behind the scenes) I do have a heap dump off the live server when it's happening, if I wanted to find the reference it's hanging on to, is this the right thing to be looking at? (This is one of the 1,628 classloaders nearest GC root)

I really don't understand the screenshot, the field names on the left and the associated types on the next column seem completely random

That makes 2 of us Never mind then, thanks anyway.