Thanks Mark and Jody for the quick reply! I'm glad there wasn't any serious memory leak, hope I didn't raise any false alarms. Maybe what I was seeing is just uDig and the postgres driver warming up? We've been trying to tweak our memory use, and garbage collection settings for low-end hardware, and maybe I was being too sensitive... I'd really enjoy a chance to help out on a project as nice as uDig! :) Should I just send Jesse an email?
Thanks again for your help, I'll build from source and use a profiler, and a much larger dataset next time.... David > Date: Wed, 3 Jun 2009 21:33:44 +1000 > From: Jody Garnett <[email protected]> > Subject: Re: [udig-devel] Memory usage best practices, and old postgis > layer leak? > To: User-friendly Desktop Internet GIS > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset=ISO-8859-1 > > I have put another 15mins into redrawing and panning; and have not run > out of memory. I can make memory use go up and down by adding and > removing layers - this is to be expected since we keep a raster per > layer in order to draw the features into. If anyone wants a rainy day > project we could really cut down the space we use in memory by using > the correct bit depth for the layer we are drawing (no reason to > reserve full 32 bit RGBA if we are just drawing a two color image). > > So I have not really been able to reproduce this problem - any suggestions? > Jody > > On Wed, Jun 3, 2009 at 9:16 PM, Jody Garnett <[email protected]> wrote: > >> 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 <[email protected]> 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 >>>> <[email protected]> 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 >>> >>> _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
