I’ve successfully performed an upgrade of a 6.7 system to 7.2 following the instructions provided (update PSO tools, apply latest patch, upgrade, apply latest 7.2 patch + PSO tools). However running publishes which consistently completed successfully under the pre-upgrade 6.7 system now cause out of memory errors like this:
java.lang.OutOfMemoryError: PermGen space
2013-01-26 02:18:34,526 ERROR [org.apache.catalina.connector.CoyoteAdapter] An exception or error occurred in the container during the request processing
Has something fundamental changed in the publishing engine that causes very large systems to show this kind of behaviour? At the point of error the system simply stops responding to any requests and has to be killed. I suppose a support call is imminent but if anyone can shed light on this it would be appreciated. This is on a 64 bit system and the Rhythmyx java.exe will reach between 1.5 and 2Gb of memory before erroring. No -Xmx value is set in the .lax file but even when it is, for example, set to -Xmx1536m it just means the error happens at that point.
Cheers, Andrew
How much memory do you have on the system? We have specified -Xmx2560m and -XX:MaxPermSize=786m in RhythmyxServer.bin.lax (YMMV)… You may want to specify what the max perm size should be on your system…
We ran into this when we upgraded to the 64 bit jvm and fixed it by increasing the maxpermsize. You’ll have to play around with it a bit to tune it to your settings.
Seems there’s an issue in 7.2 that’s being fixed by tech support. I also upped MaxPermSize, but in any case 7.2 64-bit publishing times are significantly slower than 6.7 32-bit until the fix comes through, at least for me.
Hi Andrew,
Do you know whether the issue was ever resolved?
I’m setting JVM settings as per directions - but would be good to know what was causing it.
Cheers,
Bal
Hi Bal - setting maxpermsize to 256mb or more solved it for us, by default it’s set to 128.
As for the slow publishing, patch 475 fixed that…
Cheers, Andrew
Thanks Andrew - ended up following Jitendra’s earlier response and upped in to 768 - seems to work so far 
Cheers,
Bal
Permgen memory is basically used for the storing of Java classes by the JVM. For most implementations running 7.2+, 256MB should suffice. 768M seems really high to me, 256M really should be enough in most environments.
Content Types and custom java code do impact Perm Gen requirements. So this is the variable between environments. The more content types and custom java classes / jars that are deployed in an instance the higher the Perm gen requirements will be.
Out of curiosity, how many content types / extension classes do you all have in your various implementations?
-n
[QUOTE=balcheema;20928]Thanks Andrew - ended up following Jitendra’s earlier response and upped in to 768 - seems to work so far
Cheers,
Bal[/QUOTE]
75 content types and around 20+ extensions of various sorts contained in two jars.
For folks seeing the OOM errors on Perm Gen Size. Try using the following flag on the Java Options line with a 256MB maxpermgen size.
-Dcom.sun.xml.bind.v2.bytecode.ClassTailor.noOptimize=true
This disables a compiler “optimization” option that generates dynamic classes for certain XML documents. In my testing, setting a larger PermGenSpace allows for allot more dynamic classes, but they eventually get garbage collected and then have to be regenerated. The net result is that this will actually slow the system down and can trigger rapid Garbage Collection cycles, and using memory that is not required. This dynamic byte code generation also occurs during Publishing when this flag is left at the default.
-n
