
Hi, MemoryAnalyzer is much more memory effective than jhat. It usually needs about the same amount of memory as is size of heap dump. -- Jiri On Wed, Nov 14, 2012 at 11:15 AM, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hello Jiri,
thanks for the hint. I tried that in the past, but the dump was far too large and jhat always crashed. All versions r225 to r231 allocate millions of small objects. Will see if it helps now.
Gerd
------------------------------ Date: Wed, 14 Nov 2012 11:02:03 +0100 From: jiri.klement@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter improvements
Hi,
in case you have trouble with reproducing the problem, there is java option -XX:-HeapDumpOnOutOfMemoryError. Uli can run splitter with this option and then send you produced hprof file which you can open in MemoryAnalyzer or jhat. There you will see all allocated objects, what takes most memory and in case of memory leaks what keeps objects in memory.
On Tue, Nov 13, 2012 at 6:51 PM, Gerd Petermann < gpetermann_muenchen@hotmail.com> wrote:
Hi,
I want to reproduce the problem, but I don't see a file with 1.9GB at this place: http://140.78.94.22/osm/
Where am I wrong? Gerd
------------------------------ Date: Tue, 13 Nov 2012 18:15:43 +0100 From: ulibaer@gmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: [mkgmap-dev] splitter improvements
I think the memory requirements are more dependent on the data than on the splitter version: I have a self created data set consisting of germany + ~50 kilometers plus the data from iceland cut with osmconvert.exe from the europe.osm.pbf from geofabrik, which is processed without errors with versions 225, 229, 230 and 231 using 32-Bit-jvm with Xmx1376m. When i use the about the same sized 1.9 GB "germany+"-dataset from here: ( http://140.78.94.22/osm/ ) i can't get thru the data without java heap overflow, even with 64-Bit-jvm given Xmx3000m. I think there is some kind of endless loop or the like, which causes the algorithm to overflow the memory in some circumstances.
Anyway, good work until now! I'm eager to test further splitter versions don't requiring the giant overlap-values for routing.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev