jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
Signup
GeoServer
  • GeoServer
  • GEOS-3219

Memory Leak?

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Bug Bug
  • Status: In Progress In Progress
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 1.7.5
  • Fix Version/s: None
  • Component/s: WCS
  • Labels:
    None
  • Environment:
    1.7.5 - windows Vista
  • Number of attachments :
    0

Description

I have a very large GeoTIFF (1.2GB) I have added to GeoServer as a coverage. This one - http://ueod-globe.net/globe/TrueMarble_GeoTIFF/TrueMarble.250m.21600x21600.H4.tif.gz (8MB download, nicely compressed because most of it is ocean).

I tried to download the dataset using WCS (this URL: <http://<host>:8080/geoserver/wcs?request=GetCoverage&version=1.1.1&identifier=j2:TrueMarble.250m.21600x21600.H4&SERVICE=wcs&FORMAT=image/geotiff&boundingbox=-90,135,-45,180,urn:ogc:def:crs:EPSG::4326> ) - sure enough it returns the image, but I cancel before it starts downloading. GeoServer then proceeds to fill it's RAM quota (1gig!) and never frees it, with the console giving the OutofMemoryError and Process Explorer reporing Geoserver is sitting on 1.1 to 1.2Gig of RAM (but not actually doing anything - no CPU processing, no disk access, nothing).

I restart GeoServer, and try a smaller dataset (180MB geotif). I use the exact same URL changing only the identifier. This one /should/ return "no intersection in BBOX" because there's no data in the given co-ord range, but it does return data. An 80MB EML file (whatever that is) that contains something like this:

MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_Part_0_28089599.1246536971975"

------=_Part_0_28089599.1246536971975
Content-Type: text/xml
Content-Transfer-Encoding: 7bit
Content-ID: <urn:ogc:wcs:1.1:coverages>

<?xml version="1.0" encoding="UTF-8"?><wcs:Coverages xmlns:wcs="http://www.opengis.net/wcs/1.1.1" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ogc="http://www.opengis.net/ogc" xmlns:ows="http://www.opengis.net/ows/1.1" xmlns:gml="http://www.opengis.net/gml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/wcs/1.1.1 http://193.63.128.51:8080/geoserver/schemas/wcs/1.1.1/wcsCoverages.xsd"><wcs:Coverage><ows:Title>Wales_SE is a Tagged Image File Format with Geographic information</ows:Title><ows:Abstract>.\data_dir\coverages\landsat\Wales_SE.tif</ows:Abstract><ows:Identifier>j2:Wales_SE</ows:Identifier><ows:Reference xlink:href="cid:theCoverage"/></wcs:Coverage></wcs:Coverages>
------=_Part_0_28089599.1246536971975
Content-Type: image/tiff
Content-Transfer-Encoding: base64
Content-ID: <theCoverage>

TU0AKgAAAAgAEAEAAAMAAAABISEAAAEBAAMAAAABHcUAAAECAAMAAAADAAAA0AEDAAMAAAABAAUA
AAEGAAMAAAABAAIAAAEVAAMAAAABAAMAAAEaAAUAAAABAAAA2AEbAAUAAAABAAAA4AEoAAMAAAAB
AAEAAAFCAAMAAAABAQAAAAFDAAMAAAABAQAAAAFEAAQAAAP8AAAA6AFFAAQAAAP8AAAQ2IMOAAwA
AAADAAAgyISCAAwAAAAGAAAg4IevAAMAAAAQAAAhEAAAAAAAAAAIAAgACAAAAAAAAQAAAAEAAAAB
AAAAAQAAITAAACQjAAAnFgAAKgkAACz8AAAv7wAAMuIAAFlWAAHCXAACrmgAAx9LAAM00QADN8QA
Azq3AAM9qgADQJ0AA0OQAANGgwADSXYAA0xpAANPXAADUk8AA1VCAANYNQADWygAA14bAANhDgAD
ZAEAA2b0AANp5wADbNoAA2/NAANywAADdbMAA3imAAN7mQADfowAA4F/AAOEcgADh2UAA4pYAAQw

[90 million more characters of that]

Gg6FoeiaLo2j6RpOlaXpmm6dp+oajqWp6pquravrGs61reua7r2v7BsOxbHsmy7Ns+0bTtW17Ztu
3bfuG47lMqAg
-----=_Part_0_28089599.1246536971975-

As well as that, the GeoServer instance suddenly starts using 900MB of RAM which doesn't get cleared when the image has finished being transferred. It's now about 5 mins after the image was transferred and I've not made any more requests to the Geoserver for anything, yet the 900MB is still taken. Almost certainly a memory leak

Note - these are my Java starting parameters:
%RUN_JAVA% -Xms128M -Xmx1024M -XX:PermSize=64M -XX:MaxPermSize=256M
(the system has 4GB of RAM).

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • Work Log
  • History
  • Activity
Hide
Permalink
Andrea Aime added a comment - 02/Jul/09 7:28 AM

GeoServer has no way to detect that the client dropped the request (the servlet specification does not have any way to detect that, at least as far as I know), and will continue processing it no matter what the client did. If the source data is not tiled you'll get a huge memory consumption and there is nothing we can do about it

Show
Andrea Aime added a comment - 02/Jul/09 7:28 AM GeoServer has no way to detect that the client dropped the request (the servlet specification does not have any way to detect that, at least as far as I know), and will continue processing it no matter what the client did. If the source data is not tiled you'll get a huge memory consumption and there is nothing we can do about it
Hide
Permalink
Jonathan added a comment - 02/Jul/09 7:32 AM

Ok. But that doesn't explain why the memory is still taken 5 mins after the transfer is complete - hence my suppostion it's a leak.

Also - what's with the EML file?

Show
Jonathan added a comment - 02/Jul/09 7:32 AM Ok. But that doesn't explain why the memory is still taken 5 mins after the transfer is complete - hence my suppostion it's a leak. Also - what's with the EML file?
Hide
Permalink
Jonathan added a comment - 02/Jul/09 8:09 AM

Note - I've figured out the EML (and want to shoot whoever wrote the WCS 1.1.1 spec ).

Show
Jonathan added a comment - 02/Jul/09 8:09 AM Note - I've figured out the EML (and want to shoot whoever wrote the WCS 1.1.1 spec ).
Hide
Permalink
Jonathan added a comment - 02/Jul/09 8:24 AM

Just tried serving a file-pyramid layer (1.6GB) using the &store=true. After about 50mins of processing time (two cores, so 25mins real-time) It returns this error:

<ows:ExceptionReport version="1.1.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://193.63.128.51:8080/geoserver/schemas/ows/1.1.0/owsAll.xsd">
−
<ows:Exception exceptionCode="NoApplicableCode">
−
<ows:ExceptionText>
java.lang.OutOfMemoryError: Java heap space
Java heap space
</ows:ExceptionText>
</ows:Exception>
</ows:ExceptionReport>

The memory wasn't freed.

Show
Jonathan added a comment - 02/Jul/09 8:24 AM Just tried serving a file-pyramid layer (1.6GB) using the &store=true. After about 50mins of processing time (two cores, so 25mins real-time) It returns this error: <ows:ExceptionReport version="1.1.0" xsi:schemaLocation="http://www.opengis.net/ows/1.1 http://193.63.128.51:8080/geoserver/schemas/ows/1.1.0/owsAll.xsd "> − <ows:Exception exceptionCode="NoApplicableCode"> − <ows:ExceptionText> java.lang.OutOfMemoryError: Java heap space Java heap space </ows:ExceptionText> </ows:Exception> </ows:ExceptionReport> The memory wasn't freed.
Hide
Permalink
Jonathan added a comment - 05/Jul/09 3:27 PM

If it helps, this also appears to occur on version 1.0.0 requests too.
Small querys (giving an output image of only about 100kbytes) also don't de-allocate memory by the looks of it, though they're harder to spot because of the small amount taken per query.

Show
Jonathan added a comment - 05/Jul/09 3:27 PM If it helps, this also appears to occur on version 1.0.0 requests too. Small querys (giving an output image of only about 100kbytes) also don't de-allocate memory by the looks of it, though they're harder to spot because of the small amount taken per query.
Hide
Permalink
Steven M. Ottens added a comment - 12/Oct/09 8:58 AM

I have the same issue with Geoserver 1.7.6 on windows 2003. Each getCoverage request increases the memory by about 80MB and once the request is finished, it doesn't free the memory. Resulting in a OutOfMemoryError after a while:

<?xml version="1.0" encoding="UTF-8"?><ServiceExceptionReport version="1.2.0" xmlns="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wcs/1.0.0/OGC-exception.xsd"> <ServiceException code="problem with CoverageResults">
java.lang.IllegalArgumentException: java.lang.OutOfMemoryError: Java heap space
java.lang.OutOfMemoryError: Java heap space
Java heap space
</ServiceException></ServiceExceptionReport>

Show
Steven M. Ottens added a comment - 12/Oct/09 8:58 AM I have the same issue with Geoserver 1.7.6 on windows 2003. Each getCoverage request increases the memory by about 80MB and once the request is finished, it doesn't free the memory. Resulting in a OutOfMemoryError after a while: <?xml version="1.0" encoding="UTF-8"?><ServiceExceptionReport version="1.2.0" xmlns="http://www.opengis.net/ogc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.opengis.net/ogc http://schemas.opengis.net/wcs/1.0.0/OGC-exception.xsd "> <ServiceException code="problem with CoverageResults"> java.lang.IllegalArgumentException: java.lang.OutOfMemoryError: Java heap space java.lang.OutOfMemoryError: Java heap space Java heap space </ServiceException></ServiceExceptionReport>
Hide
Permalink
Fredrik Holmqvist added a comment - 16/Dec/10 7:04 AM

I just added some info to the GEOT-2217 bug, which might be the same problem. Havn't seen anything obvious in the code though.

Show
Fredrik Holmqvist added a comment - 16/Dec/10 7:04 AM I just added some info to the GEOT-2217 bug, which might be the same problem. Havn't seen anything obvious in the code though.

People

  • Assignee:
    Simone Giannecchini
    Reporter:
    Jonathan
Vote (0)
Watch (1)

Dates

  • Created:
    02/Jul/09 7:24 AM
    Updated:
    16/Dec/10 7:04 AM
  • Atlassian JIRA (v5.2.7#850-sha1:b2af0c8)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.