Hi Christian Oh, that it were so simple! When WebSphere crashes, it takes out the whole server, and I don't believe it has the time to create a core dump file. I have tried killing it before it gets too far down this process with a kill -3 <pid> ( as I can see the memory usage and paging quickly climb on topas), but although the coredump file looked OK to me, neither tool recognised it as such.
I have to say, I think this is a WebSphere issue as well as a GeoServer issue, and am trying to document the bug as well as I can in order to raise it with IBM. I don't believe that a java app should be capable of bringing down a server, and I'm sure its just a case of tuning the WAS properly. Thanks Rob On 6 August 2010 08:55, <[email protected]> wrote: > 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
