Access Share website locks cpu at 100%

[brazen]

When I access the share website, I can browse around for a bit, but if I try to view a document, then then every Alfresco server locks up and top show java maxing out the cpu at 100%.  I left this overnight and the cpu never did go down.  I have to restart tomcat to make it go away and to be able to access the Alfresco services again.  Any ideas why this is doing this?

My installation is just like here: http://blog.mycroes.nl/2010/04/installing-alfresco-33-on-ubuntu-lucid.html except my server has 3G of RAM so I used the java opts from the installation documentation.  Also, mysql is on a separate server.  Other than that, i just installed tomcat6 on Ubuntu, then deployed the alfresco.war and share.war files to it.

The only thing I wondered is if it is common to install tomcat from the Ubuntu repos, or if the "standard" and "supported" installation is to use the tomcat bundle?  And maybe that would have something to do with my problem?

UPDATE:  Fixed by changing the JAVA_OPTS in /etc/defaults/tomcat6 but I don't understand why, or if these JAVA_OPTS are optimal.  See posts below for details.  I'd really like someone to explain the problem with the JAVA_OPTS.

[brazen]

The problem actually seems to be rather sporadic as to when it happens.  Sometimes I can log in to share, sometimes I can't.  Sometimes I can get all the way to creating a new text document, sometimes I can't.  Sometimes it happens when I click to view a document, and sometimes it actually shows the page for the preview and then stops/maxes-out.  I can NEVER get so far as to actually show the preview.  The farthest I ever get is to show the document preview page but then it says something like "generating preview" and stays there.  I've let it set for an hour just to see, and no change.

I even tried uninstalling all openoffice packages from Ubuntu and install the debs downloaded from the openoffice website, but no change.

[brazen]

Ok I fixed the problem by change the JAVA_OPTS in /etc/default/tomcat6, but I'm afraid my JAVA_OPTS may still not be optimal.  Keep in mind, I'm on a VMWARE ESX Server virtual machine with 3G of RAM and 4 cpus assigned to this virtual machine.

Here is how I originally had my JAVA_OPTS, as suggested by the Alfresco installation guide for a machine with more than 2G of ram:

JAVA_OPTS="${JAVA_OPTS} -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -server -Xss1024K -Xms1G -Xmx2G -XX:MaxPermSize=128M -XX:NewSize=512m -XX:CMSInitiatingOccupancyFraction=80"
‍‍‍‍

I was looking through, the tomcat bundle and got these JAVA_OPTS from it's configuration.  So I commented out all JAVA_OPTS in /etc/default/tomcat6, and put this in:

JAVA_OPTS="-Xms512m -Xmx1024m -Xss1024k -XX:MaxPermSize=256m -XX:NewSize=256m -server"
‍‍‍

The only possibly offending option I can see is using the CMS garbage collecter, but I've seen numerous places suggest using this.  Or maybe including $JAVA_OPTS is pulling in something bad.  Any thoughts?

[brazen]

Through meticulously changing each java_opts settings, one at a time, and then testing… I've found the offending settings to be -XX:MaxPermSize.  If I set it to 128m, which is what it should be set at according to the jvm tuning wiki page and the installation guide, then I have the problem with share.  If I set it to 256m, then it works fine.

Has anybody else experienced this?  Does it work fine for other people with -XX:MaxPermSize=128m ?  Would there be any advantage to setting it to something even higher, such as 512m?

My java_opts line in /etc/default/tomcat6 ends up being:

JAVA_OPTS="${JAVA_OPTS} -Xms1G -Xmx2G -Xss1024k -XX:MaxPermSize=256m -XX:NewSize=512m -server -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=80"
‍‍‍

[kevinr]

Yes this is a problem with many large webapps, it is not an Alfresco problem as such, the JVM needs a lot of space to load in all the classes for a large app plus large J2EE container (TomCat is small, but JBoss is bigger) - so 256MB is probably needed - especially on 64bit machines!

Cheers,

Kev