Closed jpylypiw closed 2 years ago
Hi @jpylypiw,
this is most likely due to needing to increase the memory mapping count.
For our machines that run the planet builds, we add the following to the /etc/sysctl.conf
file:
vm.max_map_count=81920
Hi @rabidllama, thank you for the fast reply! I increased the value this morning and the container is running since six hours without any issue. I will keep you updated if this fixed the issue but currently it is looking very good.
Here's what I did
I am using the docker image on a rather large hardware system.
Specs: Intel® Core™ i7-8700 Hexa-Core 128GB DDR4 RAM 2x 1TB NVMe SSD Gigabit Ethernet
My system is managed by ansible so I can not use the docker compose directly. This is my ansible code:
As OSM File I use the Planet OSM from bbbike.org since it does not contain any meta data, which shrinks the file a lot. The file is only 48GB instead of 63GB of the whole planet. I hope this speeds up the import process.
I also use a custom ors-config.json file which I show you here:
There is only one profile active which is "driving-car".
Here's what I got
The import was running rather smooth since it created the elevation cache files just in a few hours. After a few hours I got a error:
This is the whole log:
Here's what I was expecting
Since the RAM in XMX is more than double the size of the pbf file I thought the import would work fine. The system had more RAM and SWAP ready, so I also checked the OOM killer, but there was no action by the OOM killer. I am kinda speachless since I have no idea how I can solve this issue. I need this working for a customer. Do you have any idea what I can do to solve the issue?
Here's what I think could be improved