Osrm-backend: [exception] std::bad_alloc

[kimjohans]

Hi all,

on running command
osrm-routed europe-latest.osrm

i got the following error:

[info] starting up engines, v5.21.0
[info] Threads: 8
[info] IP address: 0.0.0.0
[info] IP port: 5000
[info] RAM: peak bytes used: 3411968
[warn] [exception] std::bad_alloc
[warn] Please provide more memory or consider using a larger swapfile

Of course a checked all other topics with same problems, but they all are too old (2013/2015) and have no matching solution.

It is a virtual server with 16 GB RAM, almost free:
free -h

              Gesamt   belegt    frei        gemns. Puffer/Cache verfügbar
Speicher:         16G         57M        629M        1,1M         15G        5,9G
Auslagerungsspeicher:          0B          0B          0B

There is no way to create an extra swap file or increase the RAM.
But, please, ... 16 GB of RAM should be enough for running the europe map.
64 GB RAM is quite unrealistic und unpayable.

Where can i disable the RAM allocation ?
Yes, the requests will be handled (much) slower, but that's ok.

I found this solution, but the code has changed since 2015 and the lines are not there any more:
https://github.com/Project-OSRM/osrm-backend/issues/1698#issuecomment-144003177

_Used OS_
Linux 4.15.0 #1 SMP Thu Aug 23 19:33:51 MSK 2018 x86_64 x86_64 x86_64 GNU/Linux
Ubuntu 18.04.2 LTS

Thanks !

[grib0]

Starting from 5.20.0, the RAM consumption is 10% higher (see #5251)
There are some plans to decrease the RAM but no date (see #5253)
For what I measure, the France data uses 6GB of RAM, so 16GB for all Europe seems too low...
See this one also (#5265)

[kimjohans]

Thanks for those infos. Reducing the RAM should have higest priority (my two-cents).

I would like to disable those RAM loading ... of course distance calculation will need more time. But that's ok. 32 or 48 GB RAM is far too much.

Is there no possibility to use databases or something like that ?

I will not start an arguing about the RAM - i simply need a solution to run those distance calculation with lower RAM.

Thanks.

[jcoupey]

@kimjohans OSRM's approach to routing is about being very fast, especially for huge table requests. The drawback is that it requires time and resources for pre-processing. The extra memory required is a price to pay for the performance. If you want/need another trade-off with slower computation but less resources, you probably need another routing engine.

[danpat]

One option that you've got now is to use the mmap dataloader instead of loading everything into RAM directly:

./osrm-routed --mmap=on europe-latest.osrm

this will cause OSRM to read data from disk on-demand. The filesystem will cache reads, so your first few queries will be slow-ish, but subsequent queries will speed up as more of the datafiles end up in the page cache.

[kimjohans]

@kimjohans OSRM's approach to routing is about being very fast, especially for huge table requests. The drawback is that it requires time and resources for pre-processing. The extra memory required is a price to pay for the performance. If you want/need another trade-off with slower computation but less resources, you probably need another routing engine.

Really ?

(1) that response is not helpful, because mostly developers (like i am too) are gald about feedback, problems and wishes to improve their software
(2) telling a "customer" (as far as you might see your users as customers, which i do not believe) to use another software is one of the most arrogant and dis-respectful answer you can give. i would NEVER say something like this to one of my customers. Never.
(2b) if you're not a developer of that group ... why do you answer on requests when you're not posting help (or you are not able to help) ?

One option that you've got now is to use the mmap dataloader instead of loading everything into RAM directly:

./osrm-routed --mmap=on europe-latest.osrm

this will cause OSRM to read data from disk _on-demand_. The filesystem will cache reads, so your first few queries will be slow-ish, but subsequent queries will speed up as more of the datafiles end up in the page cache.

Thank you very much for that helpful idea and trick.
I'll try it out tomorrow !

[jcoupey]

why do you answer on requests when you're not posting help (or you are not able to help) ?

I guess I had this crazy idea that providing a bit of context might put the memory requirements into perspective.

[danpat]

@kimjohans I'm with @jcoupey on this one - OSRM began as a PhD project by @DennisOSRM with the aim to demonstrate very fast routing queries on large networks - speed was the primary concern, not minimizing memory usage. That core concept has not really gone away, although we have done a lot of work to only use the minimum memory necessary to maintain performance.

Just because your use-case doesn't require OSRM's best-case performance doesn't mean we should drop that capability in order to use less memory. OSRM is used in many situations where the high performance is desperately needed (situations that involve calculating hundreds of millions of routes).

Also, Europe is large - there are 264,877,512 possible turns in the europe extract I'm using - it takes a lot more than 1 byte per edge to store this data in a way useful for navigation, where do you expect it all to get stored? We can't magically shrink the world. At roughly 20GB of data, that gives us about 75 bytes to store the source, target, road name, turn type, restriction information, travel speed, weight, and distance. It adds up quickly, especially when multiplied by a large network.

I'm going to close this ticket, I think it's reached the end of its usefulness.