Large Permgen size + performance impact

Question

We are running a liferay portal on tomcat 6. Each portlet is a contained web application so it includes all libraries the portlet itself requires. We currently have 30+ portlets. The result of this is that the permgen of our tomcat increases with each portlet we deploy.

We now have two paths we can follow. Either move some of the libraries which are commenly used by each of our portlets to the tomcat shared library. This would include stuff like spring/hibernate/cxf/.... to decrease our permgen size Or easier would be to increase the permgen size.

This second option would allow us to keep every portlet as a selfcontained entity.

The question now is, is there any negative performance impact from increasing the permgen size? We are currently running at 512MB. I have found little to no information about this. But found some post were people are talking about running on 1024MB permgen size without issues.

Winkelman

I wouldn't expect a 1 GB PermGen to cause a problem. – Colvin

Related question : https://mcmap.net/q/1354414/-are-there-any-benefits-to-keeping-maxpermsize-small/1140748 – Lindo

This doesn't answer your question, but adds another aspect: I consider the decision to have 1 portlet per plugin an artificial limitation. With the number of portlets you give, I bet there are some related where I'd recommend to consider packaging related ones together. This will take care of your pains and IMHO increase overview over your plugins. – Anglicism

We already have grouped up some of them, the biggest problem with changing it now is that Liferay keeps references to the application context in it's portlet configuration. So if we change how the portlets are grouped per webapplication context, we will break some of the currently deployed portlets. – Winkelman

Answer 1

As long as you have enough memory on your server, I can't imagine anything can go wrong. If you don't, well, the Tomcat wouldn't even start, probably, because it wouldn't be able to allocate enough memory. So, if it does start up, you're good. As far as my experience goes, 1GB PermGen is perfectly sound.

The downside of a large PermGen is that it leaves you with less system memory you can then allocate for heap (Xmx).

On the other hand, I'd advise you to reconsider the benefits of thinking of portlets as self-contained entities. For example:

• interoperability issues: if all the portlets are allowed to potentially use different versions of same libraries, there is some risk that they won't cooperate with each other and with the portal itself as intended
• performance: PermGen footprint is just one thing, but adding jars every here and there in portlets will require additional file descriptors; I don't know about Windows, but this will hurt linux server's performance in the long run.
• freedom of change: if you're using maven to build your portlets, switching from lib/ext libs to portlet's lib libraries is just a matter of changing the dependencies scope (this may be more annoying with portal libs); as far as I remember, Liferay SDK also makes it easy to do a similar switch with ant to do a similar switch in a jiffy by adding additional ant task to resolve the dependencies and deleting them from portlet's lib as required

Harelip

perm gen is not part of the java heap, it wont have any effect on Xmx – Courson

It won't on it own - but it'll leave you with less memory to allocate for Xmx, won't it? – Harelip

yes, you're right Michal - didn't read 'less memory' as 'less system memory'. – Courson

Answer 2

PermGen memory can be garbage collected by full collections, so increasing it may increase the amount of GC time when a full collection takes place.

These collections shouldn't take place too often though, and would typically still take less than a second to full GC 1GB of permgen memory - I'm just pulling this number from (my somewhat hazy) memory, so if you are really worried about GC times to some timing tests yourself (use -verbose:gc and read the logs, more details here)

Uneducated

Answer 3

Permgen size is outside of OLD Gen - so please don't mixed up . Agreed on the 2nd point - we can increase the permsize as much as we can do - as memory is pretty cheap but this would raise some question on how we are managing our code. why the heck we need this much of perm -Is JTa consuming that much - how many class we are loading ? How many file descriptors the app is opening ( check with lsof command) . We should try to answer those.

Arterial

This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post. – Dani

Since, I guess, the accusation of mixing up was pointed at my answer, I reworded the phrase in question a bit to make it more clear. I simply meant that increasing the slice of system memory given to PermGen will leave you with less "cake" to then give to Xmx. As for your question of memory usage, well, you are absolutely right in your confusion, but the OP is running liferay, and liferay creates separate ClassLoaders for each portlet you deploy on it. This may mean the whole of, e.g., spring being classloaded multiple times and this is how PermGen easily goes through the roof with Liferay. – Harelip