| Re: [udig-devel] Memory usage best practices, and old postgis layer leak? |
Mark and I had a look; and I have not run out of memory yet. We were slowed down because the svn server is down :-( A couple things: - I did find an easy way to turn on the heap widget when running udig - as a trace option - when restarting my postgis layers were still in my map; but my postgis instance was not in the catalog (so I have at least one bug to hunt down) Using the heap widget I was able to hit the garbage collect button after each render - and return to 26MB footprint (I was testing with a massive dataset that takes 3 minuets to draw so if there was a memory leak I would not be able to finish drawing). Jody On Wed, Jun 3, 2009 at 2:34 PM, Mark Leslie <mark.leslie@xxxxxxxxxxxx> wrote: > Jody's brought this to my attention so I'll have a look at it later this > evening. I agree that there shouldn't be any leaks, and it's concerning > that you may have found one. PostGIS support should be one of our more > stable datastores. > We'll let you know what we find. > -- > Mark > > > Jody Garnett wrote: >> >> A couple quick answers... >> >> There really should not be a memory leak :-) Have you tested with a >> profiler to see what is holding onto the memory? I know we can control >> how many rows the jdbc driver gulps down at a time (default is 200 or >> something). Is it a constant memory leak - or does it get worse over >> time ... each pan or zoom etc should issue a new request; so the >> metric of 6 megs per layer does not make much sense to me right now. >> >> Upgrading to 1.2 should not help or hinder this issue; but until we >> find the cause I cannot tell for sure. >> >> The best way to plan for a stable 1.2 release is to help out in the >> code sprint Jesse is planning. This will both give you a feel for >> where the code base is at; and give you a first hand impression of >> where we are at. I am doing a tutorial around uDig 1.2 at FOSS4G this >> year; and I have a set feature list in mind - however I am willing to >> cut scope to get a release out so your volunteer efforts would be >> helpful :-) >> >> Jody >> >> >> >> >> On Wed, Jun 3, 2009 at 5:57 AM, David Middlecamp >> <dmiddlecamp@xxxxxxxxxxx> wrote: >>> >>> Hi Everybody, >>> >>> Having done some research, it seemed like the time to ask the >>> experts... (it's a development question, really) >>> >>> I'm currently developing a application based on the uDig 1.1.1 sdk, and >>> I think I've spotted a memory leak during some recent performance >>> testing. >>> The strange part is that it's such a typical use case that I'm >>> sure someone must have spotted it ages ago. I tried to find references >>> to it across the archives (the last 6 months), the bug tracking for >>> Geotools, and the bug tracking for uDig over the last five years, and I >>> think I've found a few candidates (about 10 known issues), but I'm not >>> sure if they apply. >>> >>> Here's our test scenario: >>> I tested this across uDig 1.1.1, and uDig 1.2-M4, and our application >>> based on 1.1.1 >>> Our test map had 2 shapefile layers (small shapefiles, unprojected) >>> And 2 postgis layers, a basic table, no filters, etc. >>> >>> only step: Cause the map to redraw (and, in theory, query the >>> datastore)... (panning, zooming, hitting refresh, etc) (this can't >>> be right, right?) >>> >>> I rigged up our application to output actual used heap space, but for >>> uDig 1.1.1, and 1.2-M4 I used the Task Manager... >>> >>> During my tests, doing the same number of refreshes, etc, both uDig >>> 1.1.1, and my application (no surprise), leaked about 6 megs per postgis >>> layer in the span of a few minutes. I know the vm heap size in the >>> task manager doesn't reflect the actual memory used, so it's not >>> helpful when trying to diagnose a leak like this. >>> I would really like to upgrade to 1.2, but without actually heavily >>> modifying my application to work with 1.2, I can't tell if this >>> particular issue was fixed or not. >>> >>> We're really excited here to use the fixes and new features in the 1.2 >>> release, but is it too soon to merge 1.2-M4 into our production code? >>> (Is there a date in mind for a 1.2 stable release?) Also what uDig >>> best practices have people used to minimize their footprint, >>> and increase stability over long running times? >>> >>> Thanks, >>> David >>> >>> >>> _______________________________________________ >>> User-friendly Desktop Internet GIS (uDig) >>> http://udig.refractions.net >>> http://lists.refractions.net/mailman/listinfo/udig-devel >>> >> _______________________________________________ >> User-friendly Desktop Internet GIS (uDig) >> http://udig.refractions.net >> http://lists.refractions.net/mailman/listinfo/udig-devel > > _______________________________________________ > User-friendly Desktop Internet GIS (uDig) > http://udig.refractions.net > http://lists.refractions.net/mailman/listinfo/udig-devel >
Attachment:
trace.jpg
Description: JPEG image
