[Geoserver-users] OutOfMemory Errors

GeoServer GeoServer User
1

All…

Does anyone have experience with tuning GeoServer WMS GetMap request memory usage? Are there any known bugs in this area? I’m using GeoServer v1.3.0 connecting to a Postgres v7.4.1 database and GeoServer/Jetty is reporting OutOfMemory errors when generating maps for large datasets. According to the documentation I’ve read everything should be streamed so that it should be possible to generate a map even of a large data set without running out of memory. Are there some caveats that I’m not aware of?

Thanks for your help.

Corey

2

Hmmmm.... GetMap can use up memory, in composing the actual image to be returned with the java 2D stuff. Like it has to hold the image in memory and then write out the buffer to png, gif, ect. The streaming SVG rendering writes straight out (but it doesn't do styling).

Though still I've never had an out of memory error. How much memory is available? And how big are your datasets? Do you have filters in your SLD so that GeoServer is not attempting to draw all features? Some decimation is performed, but tuning your SLDs based on properties of your features to actually draw less is much more effective. Note also that in 1.3.1 filters are passed back to the datastore, so that will relieve even more memory usage.

Chris

Corey Puffalt wrote:

All...

Does anyone have experience with tuning GeoServer WMS GetMap request memory usage? Are there any known bugs in this area? I'm using GeoServer v1.3.0 connecting to a Postgres v7.4.1 database and GeoServer/Jetty is reporting OutOfMemory errors when generating maps for large datasets. According to the documentation I've read everything should be streamed so that it should be possible to generate a map even of a large data set without running out of memory. Are there some caveats that I'm not aware of?

Thanks for your help.

Corey

!DSPAM:1003,448eed9028236309890654!

------------------------------------------------------------------------

!DSPAM:1003,448eed9028236309890654!

------------------------------------------------------------------------

_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

!DSPAM:1003,448eed9028236309890654!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org

3

Chris,

I will have to do some further investigating. I was hoping there was a known issue with the v1.3.0 release. I realize GetMap has to use up some memory but if everything is being streamed then the actual memory requirements should remain constant (depending mostly on the image size being rendered) no matter how many features are being rendered.

The current maximum heap size is configured to 768MB. The largest dataset is around 150,000 records. The geometries are multi-linestrings (the complexity varies.) There are no rules on the SLD as all the features are equally important.

My current speculation is that it’s something to do with the code that generates labels (a possible memory leak?) as I haven’t been getting the errors with a simpler SLD that doesn’t do any labelling.

Thanks,
Corey

On 6/20/06, Chris Holmes <cholmes@anonymised.com> wrote:

Hmmmm… GetMap can use up memory, in composing the actual image to be
returned with the java 2D stuff. Like it has to hold the image in
memory and then write out the buffer to png, gif, ect. The streaming
SVG rendering writes straight out (but it doesn’t do styling).

Though still I’ve never had an out of memory error. How much memory is
available? And how big are your datasets? Do you have filters in your
SLD so that GeoServer is not attempting to draw all features? Some
decimation is performed, but tuning your SLDs based on properties of
your features to actually draw less is much more effective. Note also
that in 1.3.1 filters are passed back to the datastore, so that will
relieve even more memory usage.

Chris

4

Corey Puffalt wrote:

Chris,

I will have to do some further investigating. I was hoping there was a known issue with the v1.3.0 release.

Sorry, at least none that I know.

I realize GetMap has to use up some memory but if everything is being streamed then the actual memory requirements should remain constant (depending mostly on the image size being rendered) no matter how many features are being rendered.

Yeah, that is true.

The current maximum heap size is configured to 768MB. The largest dataset is around 150,000 records. The geometries are multi-linestrings (the complexity varies.) There are no rules on the SLD as all the features are equally important.

And your GetMap is returning all 150000 in one image? Is the out of memory error only when you're way zoomed out, or do you get it when zoomed in as well?

My current speculation is that it's something to do with the code that generates labels (a possible memory leak?) as I haven't been getting the errors with a simpler SLD that doesn't do any labelling.

Ok, let us know, and we can dig in to the code a bit. It's obviously something going wrong somewhere, we should be able to handle it without an out of memory error.

Chris

Thanks,
Corey

On 6/20/06, *Chris Holmes* <cholmes@anonymised.com <mailto:cholmes@anonymised.com>> wrote:

    Hmmmm.... GetMap can use up memory, in composing the actual image to be
    returned with the java 2D stuff. Like it has to hold the image in
    memory and then write out the buffer to png, gif, ect. The streaming
    SVG rendering writes straight out (but it doesn't do styling).

    Though still I've never had an out of memory error. How much memory is
    available? And how big are your datasets? Do you have filters in your
    SLD so that GeoServer is not attempting to draw all features? Some
    decimation is performed, but tuning your SLDs based on properties of
    your features to actually draw less is much more effective. Note also
    that in 1.3.1 filters are passed back to the datastore, so that will
    relieve even more memory usage.

    Chris

!DSPAM:1003,44986c92274421775926497!

--
Chris Holmes
The Open Planning Project
http://topp.openplans.org