Geoserver/Websphere crashes the whole AIX Box ???. I have never seen that, unbelievable. Since 10 years I am working with Websphere I always got a heapdump (Linux/zOs, Linux/ppc, Linux/Intel, AIX).
The only exception is if the disk partition is full. I assume this is not the case. No hints in native stderr either ? What about trying geoserver 2.0.2 ? What version of Websphere are you using (6.0 with sdk 5 or 7.0 with sdk 6) ? Quoting Rob <[email protected]>: > 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 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
