Hi to everyone
I was looking for this information for a production instance of ORS (routing service only)
list of hardware requirements (number of cores, total ram, disk, bogomips)
table for calculating the disk space occupation related to a portion of OSM data) and the number of profiles
table for calculating the ram consumption related to the size of the constructed graph
I was wondering if any of you have ever calculated these parameters based on openstreetmap data
Hi @stefcud,
we have some information in our wiki (https://github.com/GIScience/openrouteservice/wiki/System-Requirements) about minimum requirements for RAM as that is the main concern normally.
Please not though that all of the requirements we provide are for single profiles as building more than one easily doubles the amount of RAM needed as each profile is stored in memory after it is built.
Anyway, here is some information based on our standard planet wide builds:
CPU - In general, CPU cores are not a big concern in that at most we see 4 cores being used at once during parts of the build process.
RAM - a good rule of thumb is you need at least twice as much RAM as the size of the pbf file. This varies depending on profile, with bike and pedestrian profiles needing more and the car and hgv profiles less. We generally give 105-110GB though per profile as a minimum.
HDD - some aspects of hard disk are per profile and others are the same no matter how many profiles you build. No matter how many profiles you have on the machine, elevation and osm data stays the same. Planet wide elevation needs around 100GB, and the planet osm pbf file is towards 60GB. The graphs for each profile are between 50-80GB for the planet.
So if for example you wanted to build the planet graphs for a single bike profile, you would need 100 + 60 + 80 = 240GB disk space
Normally for RAM and HDD you can use the size of your pbf file to give a rough estimation of what is needed as the resources needed are largely dependent on the amount of data processed (note that the geographical size does not give a good estimation, as the whole of Africa has the same amount of data as Germany). So for example, the pbf file for Great Britain is 1.1GB, so we can assume that the HDD and RAM requirements are scalable. GB is 2% the size of the whole planet pbf, so for HDD we could say that you would likely need around 5GB (240 * 0.02). RAM we can assume double the pbf, so 3GB should be enough.
Obviously, these are rules of thumb, and for things like RAM the more you can give it the better (more RAM = faster build times as there is less garbage collection).
Hope that helps a bit
all your considerations are related to a machine that has to build the graph starting from the raw data right?
I was thinking of using two different machines
A) download and construction of the graph, switch on only in case of OSM data is updated
B) provision of REST routing services based on the existing graph
in this case I think that the machine B could be much smaller, in your opinion the rules of using RAM = 2 * PBFSIZE are still valid? or in case B the RAM is only proportional to the number of requests received? or even here the minimum RAM depends on the size of the graph?
We use the two server setup in our infrastructure, and though it means you need less hard drive space, yoiu still need a similar amount of RAM depending on what optimisations you use (Core-ALT, Contraction Hierarchies etc.)
So in your case, server B would only need enough HDD space to hold the graph whilst it is loaded into memory - it does not need elevation or the pbf. But it would still need a similar amount of RAM as the builder server to actually hold the graphs in memory
ah, I didn’t expect this …
so the ram is still allocated for each graph! Therefore it remains proportional to the profiles count and size of the pbf.
Other question not clear mentioned in this documentation:
- The routing optimisations (having the optimised routing algorithms needs more RAM)
in this point is not very clear what mean “optimised routing algorithms” maybe the optimization API (vroom)? Or what part of the configuration in app.config affects this.