I have added the instructions for turning on the heap widget to a page of debugging tips: - http://udig.refractions.net/confluence/display/DEV/7+Debugging+Tips
Jody On Thu, Jun 4, 2009 at 1:25 AM, David Middlecamp <[email protected]> wrote: > 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 > _______________________________________________ User-friendly Desktop Internet GIS (uDig) http://udig.refractions.net http://lists.refractions.net/mailman/listinfo/udig-devel
