Opened 9 years ago
Closed 9 years ago
#3445 closed defect (wontfix)
topology: postgres runs out of memory on loading geometry using toTopoGeom
Reported by: | rulus | Owned by: | strk |
---|---|---|---|
Priority: | medium | Milestone: | PostGIS 2.2.2 |
Component: | topology | Version: | 2.2.x |
Keywords: | Cc: |
Description
I first noticed this issue in the 2.2 branch (2.2.2dev) but could reproduce using the latest svn-trunk revision.
When loading a new geometry into an existing topology, the postgres process runs out of memory and is eventually killed by my OS (Debian).
I'm using versions
PostgreSQL 9.4.5 on x86_64-unknown-linux-gnu, compiled by gcc (Debian 5.2.1-23) 5.2.1 20151028, 64-bit POSTGIS="2.3.0dev r14623" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.9.2, 08 September 2015" GDAL="GDAL 2.0.1, released 2015/09/15" LIBXML="2.9.3" LIBJSON="0.11.99" TOPOLOGY RASTER
The statement I'm using to import the geometry:
insert into data.gwl (id, naam, topogeom) select 101, localid, topology.toTopoGeom(geom, 'gwl', 1, 0.01) from src."RBD_VL" where localid = 'Maas_VL';
Which is killed after a few minutes:
server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed.
Loading the same geometry in an empty topology is succesful.
Since there is no crash as such, getting a backtrace as described in https://trac.osgeo.org/postgis/wiki/DevWikiGettingABackTrace is not possible.
Sharing the full db is difficult, however I'm available to debug the issue further. I'm not experienced in debugging memory issues, maybe someone can give a hint on how to proceed?
Change History (4)
comment:1 by , 9 years ago
Component: | postgis → topology |
---|---|
Owner: | changed from | to
comment:2 by , 9 years ago
comment:3 by , 9 years ago
Adding a small nuance here: this might actually not be a bug
By disabling the OOM killer and raising the memory of the VM (from 2GB to 4GB) I managed to import the failing geometry without problems. It seems that it's just using more memory than I thought it would..
Thanks for the suggestions!
comment:4 by , 9 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
Thank you for confirming, will close as "wontfix" for now, but shall you feel operations are really using too much memory feel free to file a new enhancement ticket to reduce memory usage during topology population (after checking that no other similar tickets already exist)
Disabling the OOM killer should make debugging easier. Splitting the inputs to avoid a single new geometry's bounding box to intersect lots of existing components should reduce memory usage.