1

We recently upgraded from GeoServer 2.1 to the 2.5-SNAPSHOT, both from official OsGeo Centos packages, git revision, c7886eb21885c88d40029432c3178f88931ed820

We are getting the dreaded:

Rendering process failed java.lang.OutOfMemoryError: Java heap space Java heap space

errors on processing. The WMS png image we are requesting is 2600 x 2600 pixels and worked on the older version of GeoServer. If we reduce the width/height below 2000 x 2000 pixels, the image is returned. This would seem to imply some cutoff at around 15Mb, assuming 3/4 bytes per pixel, and 4 million pixels at 2000 x 2000.

We have tried setting the config variable <maxRequestMemory>50000</maxRequestMemory> in web.xml in the Geoserver config directory as suggested in the docs.

We have also tried setting Xmx via JAVA_OPTS="${JAVA_OPTS} -XX:MaxPermSize=128m -Xmx768m" in /etc/tomcat6/tomcat6.conf as suggested in the docs.

Running,

ps ax|grep tomcat

yields

/usr/lib/jvm/jre/bin/java -XX:MaxPermSize=128m -Xmx768m -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Djava.awt.headless=true -Xms256m -Xmx768m -Xrs -XX:PerfDataSamplingInterval=500 -XX:MaxPermSize=256m -Dorg.geotools.referencing.forceXY=true -DGEOEXPLORER_DATA=/var/lib/opengeo/geoexplorer -XX:MaxPermSize=128m -Xmx768m -Djavax.sql.DataSource.Factory=org.apache.commons.dbcp.BasicDataSourceFactory -Djava.awt.headless=true -Xms256m -Xmx768m -Xrs -XX:PerfDataSamplingInterval=500 -XX:MaxPermSize=256m -Dorg.geotools.referencing.forceXY=true -DGEOEXPLORER_DATA=/var/lib/opengeo/geoexplorer -classpath :/usr/share/tomcat6/bin/bootstrap.jar:/usr/share/tomcat6/bin/tomcat-juli.jar:/usr/share/java/commons-daemon.jar -Dcatalina.base=/usr/share/tomcat6 -Dcatalina.home=/usr/share/tomcat6 -Djava.endorsed.dirs= -Djava.io.tmpdir=/var/cache/tomcat6/temp -Djava.util.logging.config.file=/usr/share/tomcat6/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager org.apache.catalina.startup.Bootstrap start

which shows 768m for Xmx, which should be vastly in excess of the requirements for a 2600x2600 pixel png. This is against a dev server with no other users or requests against it. Clearly we are missing something.

  • depends on how many features in the layers you are trying to draw and how many featurestyles there are in the slds for each layer. It can be 3 or 4 times the number of features for a road layer (i.e. with casing) then multiply by the number of layers by the pixel size. – Ian Turton May 26 '15 at 14:47
  • @iant. So, you are saying each object type within an SLD is rendered independently and then they are stacked? We are dealing with OS Mastermap here, so there are a lot of styles involved, albeit only one db table and one SLD. Am I changed the correct variables, maxRequestMemory and Xmx. I have already more than doubled both, and the request works at 2305 pixels and falls over at 2306, which makes me think something else is afoot. – John Powell May 26 '15 at 15:19
  • It's not dependent on the number of layers, but on the max number of FeatureTypeStyle you have for a single layer, since GS will allocate a drawing surface for each one of them. Also, the error makes me think it's not GS own memory control, but a real out of memory happening in the JVM, so something else (parallel requests maybe) is chewing memory there – Andrea Aime May 26 '15 at 16:48
  • @AndreaAime. Thanks, but as I said, it is a dev box and I am the only user and this the only request, so parallel requests unlikely cause. As soon as this goes above 2305 x 2305 pixels it blows up and I have already doubled settings listed above. There must be another setting we are missing. – John Powell May 26 '15 at 19:24
  • Tomcat7 might also be worth a try, since you're upgrading anyway, right. – BradHards May 29 '15 at 11:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.