Hello GeoServer-Mailing List, we are experiencing problems that appear to be memory leaks of GeoServer when trying to serve tiles from a JPEG WorldImage (TIF WorldImages seem to be fine). The error is easily reproducable (see steps below) and leads to the Tomcat container’s Heap space (PS Old Gen and PS Eden, to be exact) to be filled up to 99 %, making Tomcat unresponsive and preventing GeoServer from rendering any more new tiles.## Our System:* Tomcat: Apache Tomcat/7.0.40 - Heap space for PS Old Gen is a whopping 965 MB max, PS Eden Space is 381 MB max * JVM: Oracle Corporation: 1.7.0_25 (Java HotSpot™ 64-Bit Server VM) * OS: Linux 2.6.32-358.11.1.el6.x86_64 (64 Bit) * GeoServer: 2.4.0 (but happens with 2.2.2 and 2.3.2 as well), no native JAI## Steps to Reproduce the Problem* Setup: GeoServer in a Tomcat container. * You need a WorldImage store for a JPEG file in GeoServer. —> In [GEOSERVER_DATA_DIR]/coverages/img_sample you can find the files Pk50095.tfw, Pk50095.tif and Pk50095.prj . Open the tif with an image program of your choice and save it as Pk50095.jpeg in a new folder. Make a copy of Pk50095.tfw, move it to the new folder and rename it to Pk50095.jgw . Now you can either copy the .prj-File into the new folder or you can leave it out (this file does not seem to influence the problematic behaviour). Once you have done this, add a new WorldImage Store to your GeoServer (URL is the path to the new Pk50095.jpeg) and publish the layer. If you left out the .prj-File, you have to set the layer’s declared SRS to EPSG:32633, set “Force declared” and hit “Compute from native bounds”). * Open your new layer with the GeoServer LayerPreview. Set the Tiling option to “tiled” and start zooming, panning etc. - just create lots of requests for tiles for the new layer. * If you watch your Tomcat’s heap now (with the Tomcat Manager Web App, for instance), you should see PS Old Gen filling up until it reaches 99 %. PS Eden Space will then fill up, too. Tomcat will show several threads with requests for the specific layer “hanging” in state “Service” for very long times (up to more than 30 minutes in one of our tests). * Finally, OutOfMemory errors will show up in the GeoServer log and Tomcat may become unresponsive (see attached detailed log file, look for the following errors): ERROR [geoserver.ows] - java.lang.OutOfMemoryError: Java heap space ERROR [geoserver.ows] - java.lang.RuntimeException: javax.imageio.IIOException: Improper call to JPEG library in state 202 ERROR [geotools.map] - Call MapContent dispose() to prevent memory leaks ERROR [geoserver.ows] - java.lang.OutOfMemoryError: GC overhead limit exceeded## Our Concrete Error Situation* We have a WorldImage store for a JPEG file (so we have a JPEG and a related JGW) in GeoServer and publish the JPEG as a layer with EPSG:31467. * Whenever tiles for this layer get rendered, we can see (via the Tomcat Manager Web App) its PS Old Gen Heap space continuosly filling up as described above. Tomcat will become sluggish/unresponsive. Requests for cached tiles sometimes go through apparently unaffected, but new tiles will not be rendered. * In order to get a responsive Tomcat again, we restart it. Now the heap will be (almost) empty, but it will fill up again if the JPEG WorldImage-Layer gets rendered. * We saved our original JPEG file as a TIF file and created a TGW file containing the same contents as the original JGW file. If we add this TIF file as a WorldImage Store and publish it as a layer with EPSG:31467, rendering seems to work perfectly fine and the heap space does not appear to be filling up. * Note: The original JPEG/JGW files have been in use with GeoServer since 2011 and we cannot remember having experienced these problems before! We noticed them just now after moving the GeoServer to the current system (see above). The previous system was: Linux 2.6.18-348.el5 i386, Apache Tomcat/6.0.26, JVM Sun Microsystems Inc.: 1.6.0_20 (Java HotSpot™ Client VM), GeoServer 2.2.2 . The old Tomcat doesn’t show detailed information about its heap memory in the Tomcat Manager Web App, but we can see that we only had a total available memory of 742.43 MB (much less than on the new system), and we can play around with our JPEG WorldImage layer without any problems…## Ideas* It seems to be related to the format of the WorldImage - TIFs seem to be fine, JPEGs fill up the heap space. * Is the JPEG image repeatedly loaded into heap memory for rendering, and this memory is never released (and therefore cannot be Garbage Collected)? * We tried setting the recommended options for the JVM (-Xmx256M -Xms48m), but that only made the problem worse because we had less heap than before, so it fills up faster. * It seems to be related to us moving our GeoServer to our new system - 64 bit architecture? Newer JVM? Newer Tomcat? Now, as described we found a workaround (using a TIF WorldImage instead of the original JPEG WorldImage), but this behaviour does not seem to be right. We are aware that using a JPEG or PNG as a WorldImage isn’t optimal, but it used to work fine (for our needs) until we moved to the current system… I could not find anything in JIRA about this, is this a bug in GeoServer?
Ideally with some sample data if it is data specific.
Regards,
Jonathan
This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.
Hello GeoServer-Mailing List, we are experiencing problems that appear to be memory leaks of GeoServer when trying to serve tiles from a JPEG WorldImage (TIF WorldImages seem to be fine). The error is easily reproducable (see steps below) and leads to the Tomcat container’s Heap space (PS Old Gen and PS Eden, to be exact) to be filled up to 99 %, making Tomcat unresponsive and preventing GeoServer from rendering any more new tiles.## Our System:* Tomcat: Apache Tomcat/7.0.40 - Heap space for PS Old Gen is a whopping 965 MB max, PS Eden Space is 381 MB max * JVM: Oracle Corporation: 1.7.0_25 (Java HotSpot™ 64-Bit Server VM) * OS: Linux 2.6.32-358.11.1.el6.x86_64 (64 Bit) * GeoServer: 2.4.0 (but happens with 2.2.2 and 2.3.2 as well), no native JAI## Steps to Reproduce the Problem* Setup: GeoServer in a Tomcat container. * You need a WorldImage store for a JPEG file in GeoServer. —> In [GEOSERVER_DATA_DIR]/coverages/img_sample you can find the files Pk50095.tfw, Pk50095.tif and Pk50095.prj . Open the tif with an image program of your choice and save it as Pk50095.jpeg in a new folder. Make a copy of Pk50095.tfw, move it to the new folder and rename it to Pk50095.jgw . Now you can either copy the .prj-File into the new folder or you can leave it out (this file does not seem to influence the problematic behaviour). Once you have done this, add a new WorldImage Store to your GeoServer (URL is the path to the new Pk50095.jpeg) and publish the layer. If you left out the .prj-File, you have to set the layer’s declared SRS to EPSG:32633, set “Force declared” and hit “Compute from native bounds”). * Open your new layer with the GeoServer LayerPreview. Set the Tiling option to “tiled” and start zooming, panning etc. - just create lots of requests for tiles for the new layer. * If you watch your Tomcat’s heap now (with the Tomcat Manager Web App, for instance), you should see PS Old Gen filling up until it reaches 99 %. PS Eden Space will then fill up, too. Tomcat will show several threads with requests for the specific layer “hanging” in state “Service” for very long times (up to more than 30 minutes in one of our tests). * Finally, OutOfMemory errors will show up in the GeoServer log and Tomcat may become unresponsive (see attached detailed log file, look for the following errors): ERROR [geoserver.ows] - java.lang.OutOfMemoryError: Java heap space ERROR [geoserver.ows] - java.lang.RuntimeException: javax.imageio.IIOException: Improper call to JPEG library in state 202 ERROR [geotools.map] - Call MapContent dispose() to prevent memory leaks ERROR [geoserver.ows] - java.lang.OutOfMemoryError: GC overhead limit exceeded## Our Concrete Error Situation* We have a WorldImage store for a JPEG file (so we have a JPEG and a related JGW) in GeoServer and publish the JPEG as a layer with EPSG:31467. * Whenever tiles for this layer get rendered, we can see (via the Tomcat Manager Web App) its PS Old Gen Heap space continuosly filling up as described above. Tomcat will become sluggish/unresponsive. Requests for cached tiles sometimes go through apparently unaffected, but new tiles will not be rendered. * In order to get a responsive Tomcat again, we restart it. Now the heap will be (almost) empty, but it will fill up again if the JPEG WorldImage-Layer gets rendered. * We saved our original JPEG file as a TIF file and created a TGW file containing the same contents as the original JGW file. If we add this TIF file as a WorldImage Store and publish it as a layer with EPSG:31467, rendering seems to work perfectly fine and the heap space does not appear to be filling up. * Note: The original JPEG/JGW files have been in use with GeoServer since 2011 and we cannot remember having experienced these problems before! We noticed them just now after moving the GeoServer to the current system (see above). The previous system was: Linux 2.6.18-348.el5 i386, Apache Tomcat/6.0.26, JVM Sun Microsystems Inc.: 1.6.0_20 (Java HotSpot™ Client VM), GeoServer 2.2.2 . The old Tomcat doesn’t show detailed information about its heap memory in the Tomcat Manager Web App, but we can see that we only had a total available memory of 742.43 MB (much less than on the new system), and we can play around with our JPEG WorldImage layer without any problems…## Ideas* It seems to be related to the format of the WorldImage - TIFs seem to be fine, JPEGs fill up the heap space. * Is the JPEG image repeatedly loaded into heap memory for rendering, and this memory is never released (and therefore cannot be Garbage Collected)? * We tried setting the recommended options for the JVM (-Xmx256M -Xms48m), but that only made the problem worse because we had less heap than before, so it fills up faster. * It seems to be related to us moving our GeoServer to our new system - 64 bit architecture? Newer JVM? Newer Tomcat? Now, as described we found a workaround (using a TIF WorldImage instead of the original JPEG WorldImage), but this behaviour does not seem to be right. We are aware that using a JPEG or PNG as a WorldImage isn’t optimal, but it used to work fine (for our needs) until we moved to the current system… I could not find anything in JIRA about this, is this a bug in GeoServer?
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk
thank you for your suggestion. I created an issue on JIRA for this matter (
[GEOS-6053] <http://jira.codehaus.org/browse/GEOS-6053> ) and attached some
sample data (mainly for convenience, as we can reproduce the problem with
any JPEG WorldImage).
If anyone else can reproduce this problem on similar or different
environments, I'd be interested in hearing about it!
Ideally with some sample data if it is data specific.
Regards,
Jonathan
On 20 September 2013 14:53, anwa <
a.walter@
> wrote:
Hello GeoServer-Mailing List, we are experiencing problems that appear to
be memory leaks of GeoServer when trying to serve tiles from a JPEG
WorldImage (TIF WorldImages seem to be fine). The error is easily
reproducable (see steps below) and leads to the Tomcat container's Heap
space (PS Old Gen and PS Eden, to be exact) to be filled up to 99 %,
making
Tomcat unresponsive and preventing GeoServer from rendering any more new
tiles. [...]
thank you for your suggestion. I created an issue on JIRA for this matter (
[GEOS-6053] <http://jira.codehaus.org/browse/GEOS-6053> ) and attached some
sample data (mainly for convenience, as we can reproduce the problem with
any JPEG WorldImage).
If anyone else can reproduce this problem on similar or different
environments, I’d be interested in hearing about it!
Ideally with some sample data if it is data specific.
Regards,
Jonathan
On 20 September 2013 14:53, anwa <
a.walter@
> wrote:
Hello GeoServer-Mailing List, we are experiencing problems that appear to
be memory leaks of GeoServer when trying to serve tiles from a JPEG
WorldImage (TIF WorldImages seem to be fine). The error is easily
reproducable (see steps below) and leads to the Tomcat container’s Heap
space (PS Old Gen and PS Eden, to be exact) to be filled up to 99 %,
making
Tomcat unresponsive and preventing GeoServer from rendering any more new
Sent from the GeoServer - User mailing list archive at Nabble.com.
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
thank you for your suggestion. I created an issue on JIRA for this matter (
[GEOS-6053] <http://jira.codehaus.org/browse/GEOS-6053> ) and attached some
sample data (mainly for convenience, as we can reproduce the problem with
any JPEG WorldImage).
If anyone else can reproduce this problem on similar or different
environments, I’d be interested in hearing about it!
Ideally with some sample data if it is data specific.
Regards,
Jonathan
On 20 September 2013 14:53, anwa <
a.walter@
> wrote:
Hello GeoServer-Mailing List, we are experiencing problems that appear to
be memory leaks of GeoServer when trying to serve tiles from a JPEG
WorldImage (TIF WorldImages seem to be fine). The error is easily
reproducable (see steps below) and leads to the Tomcat container’s Heap
space (PS Old Gen and PS Eden, to be exact) to be filled up to 99 %,
making
Tomcat unresponsive and preventing GeoServer from rendering any more new
Sent from the GeoServer - User mailing list archive at Nabble.com.
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
* It seems to be related to us moving our GeoServer to our new system - 64 bit architecture? Newer JVM? Newer Tomcat? Now, as described we found a workaround (using a TIF WorldImage instead of the original JPEG WorldImage), but this behaviour does not seem to be right. We are aware that using a JPEG or PNG as a WorldImage isn’t optimal, but it used to work fine (for our needs) until we moved to the current system… I could not find anything in JIRA about this, is this a bug in GeoServer?