Hi, I have a similar configuration using AIX, Linux/ppc, IBM sdk, openjdk , DB2 and Websphere or jetty.
To make it short. If your Websphere crashes it creates an heapdump, composed of 2 or 3 files. You should find these files in your profile directory (something like /opt/IBM/Webspere/AppServer/profiles/server1). There is an IBM tool http://www.alphaworks.ibm.com/tech/heaproots for analyzing the dump. For large heapdumps , please dont use the GUI version, otherwise the utility would create an heapdump for itself :-(. Command Line operation is needed. Within the last 3 years, this utility helps me to solve any problem concerning memory problems and finding the code causing these problems. I would recommend you to invest some time, I am sure this is not the last heapdump you have to study. Believe me, it is the best way to find the problem. If you have questions, please ask, I will support you. I can also analyze your heapdump, but this requires at minimum one day and this is part of my commercial support for customers. Hope this helps Quoting Andrea Aime <[email protected]>: > Rob ha scritto: >> I'm seeing a serious problem with my geoserver install, where it is >> crashing the system it is running on, following certain types of WMS >> requests. >> >> Given the fact that I am probably the only person on the list running >> GeoServer (v2.0.0) under WebSphere App Server, using IBM Java, on AIX, I >> am not expecting anybody to point me in the direction of a silver >> bullet. However, if someone could confirm my theory as to what is >> happening that is causing the issue in the first place, it might help. >> I'll try and talk through an example, and my hypothesis - made with no >> knowledge of the geoserver code whatsoever, I hasten to add! :) >> >> >> FOR AN EXAMPLE WAYWARD REQUEST >> >> I am rendering some vector data stored in Oracle Spatial. This data is >> quite detailed, and from the geoserver debug logs, I can identify the >> exact SQL used. I can run the SQL in sqlplus and the records return >> pretty much instantaneously. There are eight polygons, and eight lines. >> The lines and polygons have between 50 and 300 vertices, and are styled >> in different ways. The MBR for these records is approx 2km by 1.5km. >> >> These records render beautifully, and quickly (1-2 seconds) at 1:2000. >> [To my simple mind, this suggests that the geometries are valid, and >> that the styling is OK. I remember seeing an issue with symbols at >> these kind of scales causing problems, but none of these records would >> be styled using symbols. Basic lines and fills only] >> >> As I zoom in (and in, and in) the rendering starts to take more time >> each time, until I'm at something like 1:50. Rendering is now taking 20 >> seconds. If I zoom in until I'm at 1:2 or 1:1, I can see the memory on >> the machine be eaten up, until WebSphere starts paging like crazy and >> eventually the machine hangs. >> >> My theory is that GeoServer is trying to create an image at the same >> scale as the target bbox, but containing the entire geometries pulled >> back from Oracle. So if I request a 600x600 pixel image at 1:1 scale, >> it tries to build an internal image that would contain the 2km x 1.5km - >> i.e., a (600 x 2000=1200000) x (600 x 1500=900000) image, before it >> would cut out the 600x600 bbox of interest. >> >> Is this how it works? >> >> GeoServer does have some WMS resource consumption limits that I can >> configure, and I have these currently set to >> >> Max rendering memory - 73728 KB (up from 64Mb, as I was seeing some >> OutOfMemory issues on something else) >> Max rendering time - 20s (down from 60s - see below) >> Max rendering errors - 100 (down from 1000) >> >> Changing the max rendering time seems to have helped, as GeoServer cant >> eat all the available memory and pagespace inside 20 seconds (so far >> anyway - touch wood!), but I would have hoped that if it was a memory >> issue, that the limit stated here would be adhered to. I'd rather >> GeoServer barfed an OutOfMemory error than it taking down my entire >> server. Should this limit have stopped the problem? >> >> The next thing for me to try (within GeoServer at least) is to try and >> set up some MinScaleDenominators in the SLDs so that these features >> aren't displayed beyond 1:10. >> >> Are there any other suggestions on how to make this work/fallover >> gracefully? > > My guess is that you're using a dash array on the lines of those > polygons. There is a well known java2d bug that makes the rendering > bomb out. > > We could clip the line before passing it to the renderer, but doing it > properly is not easy and so far nobody every had spare time to work on > it, nor paid time. > > Cheers > Andrea > > > -- > Andrea Aime > OpenGeo - http://opengeo.org > Expert service straight from the developers. > > ------------------------------------------------------------------------------ > The Palm PDK Hot Apps Program offers developers who use the > Plug-In Development Kit to bring their C/C++ apps to Palm for a share > of $1 Million in cash or HP Products. Visit us here for more details: > http://p.sf.net/sfu/dev2dev-palm > _______________________________________________ > Geoserver-users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/geoserver-users > ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev _______________________________________________ Geoserver-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-users
