[mkgmap-dev] Memory limits for mkgmap and splitter

Fri Aug 7 10:28:03 BST 2009

>> Just an thought from reading the thread:
>> Multiple parsing runs with an bz2 zipped file could do worse to the 
>> performance. It would mean multiple decompressing of the input files. 
>> And in my experience decompressing bz2 costs a lot of resources.
>>
>> (In my case I'm directly using the osm.bz2 files from geofabrik as input.)
>>     
>
> Perhaps true, but you should have seen the runtime from running mkgmap
> on input files that needed more than 1.8G per area on a machine with 2G
> of RAM.  Redoing bz2 on the input a few times would have been fine
> compared to paging.  I realize this is tough, as the right tuning is heavily dependent on how much memory is available.
>   
>   
Yes, I know it from my job.
A java process starting swapping is nearly unusable. IMO the reason for 
it is the garbage collector, which has to read in the whole virtual 
memory periodically. Therefore it sometimes help to double the size of 
the virtual memory of the java machine (-Xmx ...), because the GC has to 
run less.

But in general you are right. You should do everything to stop swapping 
of java.