[Geoserver-users] GeoServer java heap space issues

Hi List,

I have take many time to read some posts about heap space issues, but I
never understand why I get this fault in my production enviroment.
I've running jdk_1.6.x with whole JAI-setup, GeoServer 1.6.3 and
tilecache_2.01. All these run under Win-Server-2003 with IIS(not the best,
realy, but I've running same prod. enviroment under linux with apache and
mod_python, this has a fantastic performance).

I get a hard problem where I take many times to understand, but I don't
understand it.....
I work with big maps(20 tiles over 10000x15000 geotiffs), which where
handled by MosaicIndexBuilder(this works greate) and a upload into
GeoServer.

Tilecache will seed the whole map before, this process can take up to three
or four days. That's ok and will provide a fast support of coverages.
Now I run into some reproducible problems. One or to days the tilecache seed
process runs quite good. After a undefined time the heap of the JVM is up to
the limit. Garbage Collection give only a little heap back and secounds
later it will be additianaly used.

The JVM has an amount of memory(600mb) and GeoServer(JAI) get's 50 percent
by a upper line of 75% percent. I think thats not the problem.

I had sniffed over the whole seed process with the jconsole tool and after
GeoServer had given me an heap space error, the tenured Gen memory pool was
up to 100 percent. It looks like many objects thats are permanent
referenced.

Edit:

Here is the stack trace:

Response:
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE
ServiceExceptionReport SYSTEM
"http://schemas.opengis.net/wms/1.1.1/WMS_exception_1_1_1.dtd
"> <ServiceExceptionReport version="1.1.1" > <ServiceException>
      java.lang.OutOfMemoryError: Java heap space
Java heap space
Details:
org.geoserver.platform.ServiceException: java.lang.OutOfMemoryError: Java
heap space
        at org.geoserver.ows.Dispatcher.exception(Dispatcher.java:1177)
        at
org.geoserver.ows.Dispatcher.handleRequestInternal(Dispatcher.java:198)
        at
org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:139)
        at
org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:44)
        at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:684)
        at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:625)
        at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:392)
        at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:347)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:689)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
        at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:459)
        at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1054)
        at
org.vfny.geoserver.filters.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:108)
        at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
        at
org.geoserver.filters.LoggingFilter.doFilter(LoggingFilter.java:69)
        at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
        at org.geoserver.filters.GZIPFilter.doFilter(GZIPFilter.java:47)
        at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:264)
        at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:107)
        at
org.acegisecurity.intercept.web.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:72)
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
        at
org.acegisecurity.ui.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:110)
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
        at
org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
        at
org.acegisecurity.ui.basicauth.BasicProcessingFilter.doFilter(BasicProcessingFilter.java:178)
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
        at
org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:229)
        at
org.acegisecurity.util.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:274)
        at
org.acegisecurity.util.FilterChainProxy.doFilter(FilterChainProxy.java:148)
        at
org.acegisecurity.util.FilterToBeanProxy.doFilter(FilterToBeanProxy.java:98)
        at
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1045)
        at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:358)
        at
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:231)
        at
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:629)
        at
org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:453)
        at
org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149)
        at
org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123)
        at
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141)
        at org.mortbay.jetty.Server.handle(Server.java:303)
        at
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:452)
        at
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:721)
        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:509)
        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:209)
        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:349)
        at
org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:320)
        at
org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475)
Caused by: java.lang.OutOfMemoryError: Java heap space

</ServiceException></ServiceExceptionReport>

I don't know any solution, or false configuration. If anyone has a idea or a
tip, i will be very pleased....
Thanks Klaus
--
View this message in context: http://www.nabble.com/GeoServer-java-heap-space-issues-tp17728841p17728841.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

2StepForward ha scritto:

Hi List,

I have take many time to read some posts about heap space issues, but I
never understand why I get this fault in my production enviroment.
I've running jdk_1.6.x with whole JAI-setup, GeoServer 1.6.3 and
tilecache_2.01. All these run under Win-Server-2003 with IIS(not the best,
realy, but I've running same prod. enviroment under linux with apache and
mod_python, this has a fantastic performance).

I get a hard problem where I take many times to understand, but I don't
understand it.....
I work with big maps(20 tiles over 10000x15000 geotiffs), which where
handled by MosaicIndexBuilder(this works greate) and a upload into
GeoServer.

Tilecache will seed the whole map before, this process can take up to three
or four days. That's ok and will provide a fast support of coverages.
Now I run into some reproducible problems. One or to days the tilecache seed
process runs quite good. After a undefined time the heap of the JVM is up to
the limit. Garbage Collection give only a little heap back and secounds
later it will be additianaly used.

The JVM has an amount of memory(600mb) and GeoServer(JAI) get's 50 percent
by a upper line of 75% percent. I think thats not the problem.

I had sniffed over the whole seed process with the jconsole tool and after
GeoServer had given me an heap space error, the tenured Gen memory pool was
up to 100 percent. It looks like many objects thats are permanent
referenced.

The JAI cache is a sort of permanent memory, once used, it won't
be given back to the heap afaik (but I'm not sure). Can you try
out with VisualVM (https://visualvm.dev.java.net/) and see if you
can get an idea of where the memory is spent using the memory
dump exploration tool as described at:
https://visualvm.dev.java.net/heapdump.html

Also, I would be interested in having a look at the dump file
you get (will be very big, compress and put it on a HTTP or FTP
server where I can grab it).

Cheers
Andrea