Can not get self-hosted USA drive-time service running

I have successfully run a container for Delaware, but can’t get USA running. I should have enough memory, but maybe that’s the problem - or maybe it’s some setting, perhaps related to memory.

Here’s what I’ve tried:

download us-latest.osm.pbf from

docker build -t usa-in-openroute .

docker run -p 8080:8080 -e BUILD_GRAPHS="True" -e JAVA_OPTS="-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms7g -Xmx14g" -e CATALINA_OPTS=" -Djava.rmi.server.hostname=localhost" $(IMAGE)
(where IMAGE is the image id)

The Dockerfile looks like this:

FROM openrouteservice/openrouteservice

COPY ./us-latest.osm.pbf /home/ors/ors-core/data/osm_file.pbf

COPY ./ors-config.json /home/ors/ors-conf

The ors-config.json is unchanged from the sample. It worked for Delaware. (perhaps a problem in there ? I can include that if needed, but it’s long so I left it out)

The response to the run command is like this:

Running container as user ors with id 1000
ORS Path: /home/ors
Catalina Path: /home/ors/tomcat
### openrouteservice configuration ###
Extract war file to /home/ors/tomcat/webapps/ors
Deploy ors with config from /home/ors/ors-conf/ors-config.json
NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/ --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/ --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
10-Aug-2023 17:24:14.318 INFO [main] org.apache.coyote.AbstractProtocol.init Initializing ProtocolHandler ["http-nio-8080"]
10-Aug-2023 17:24:25.055 INFO [main] org.apache.jasper.servlet.TldScanner.scanJars At least one JAR was scanned for TLDs yet contained no TLDs. Enable debug logging for this logger for a complete list of JARs that were scanned but no TLDs were found in them. Skipping unneeded JARs during scanning can improve startup time and JSP compilation time.
17:24:26.847 [main] INFO  org.heigit.ors.config.AppConfig - Default path of 'ors-config.json' used for configuration
17:24:26.867 [main] INFO  org.heigit.ors.config.AppConfig - Loading configuration from /home/ors/tomcat/webapps/ors/WEB-INF/classes/ors-config.json

  .   ____          _            __ _ _
 /\\ / ___'_ __ _ _(_)_ __  __ _ \ \ \ \
( ( )\___ | '_ | '_| | '_ \/ _` | \ \ \ \
 \\/  ___)| |_)| | | | | || (_| |  ) ) ) )
  '  |____| .__|_| |_|_| |_\__, | / / / /
 :: Spring Boot ::               (v2.7.12)

10 Aug 17:24:27 INFO [ors.Application] - Starting Application v7.1.0 using Java 17.0.7 on e5eb8175aa4e with PID 1 (/home/ors/tomcat/webapps/ors/WEB-INF/classes started by ors in /home/ors)
10 Aug 17:24:27 DEBUG [ors.Application] - Running with Spring Boot v2.7.12, Spring v5.3.27
10 Aug 17:24:27 INFO [ors.Application] - No active profile set, falling back to 1 default profile: "default"
10 Aug 17:24:33 INFO [ors.Application] - Started Application in 7.561 seconds (JVM running for 20.765)
10 Aug 17:24:33 INFO [logging.LoggingUtility] - Logging configuration loaded from DEBUG_LOGGING.json, logging to file /home/ors/ors-core/logs/ors/ors-logs.log
10 Aug 17:24:33 INFO [routing.RoutingProfileManager] -  Total - 10 GB, Free - 9.62 GB, Max: 18 GB, Used - 390.92 MB
10 Aug 17:24:33 INFO [routing.RoutingProfileManager] -       
10 Aug 17:24:33 INFO [routing.RoutingProfileManager] - ====> Initializing profiles from '/home/ors/ors-core/data/osm_file.pbf' (1 threads) ...
10 Aug 17:24:33 INFO [routing.RoutingProfileManager] - 1 tasks submitted.
10 Aug 17:24:33 INFO [routing.RoutingProfile] - [1] Profiles: 'driving-car', location: '/home/ors/ors-core/data/graphs/car'.
10 Aug 17:24:34 INFO [core.CoreLMPreparationHandler] - Loaded landmark splitting collection from 
10-Aug-2023 17:24:34.180 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8080"]
10 Aug 17:24:34 INFO [extensions.ORSGraphHopper] - version 4.0|2023-06-12T14:59:08Z (7,20,5,4,5,7)
10 Aug 17:24:34 INFO [extensions.ORSGraphHopper] - graph CH|car_ors|RAM_STORE|3D|turn_cost|,,,,, details:edges:0(0MB), nodes:0(0MB), name:(0MB), geo:0(0MB), bounds:1.7976931348623157E308,-1.7976931348623157E308,1.7976931348623157E308,-1.7976931348623157E308,1.7976931348623157E308,-1.7976931348623157E308, shortcuts:0 (0MB), nodesCH:-1 (0MB), shortcuts:0 (0MB), nodesCH:-1 (0MB), shortcuts:0 (0MB), nodesCH:-1 (0MB)
10 Aug 17:24:34 INFO [extensions.ORSGraphHopper] - No custom areas are used, not given
10 Aug 17:24:34 INFO [extensions.ORSGraphHopper] - start creating graph from /home/ors/ors-core/data/osm_file.pbf
10 Aug 17:24:34 INFO [extensions.ORSGraphHopper] - using CH|car_ors|RAM_STORE|3D|turn_cost|,,,,, memory:totalMB:10240, usedMB:542
jay@Jays-MacBook-Pro drive-time-server %

The computer works hard for quite a while (like 15 or 20 minutes) before hanging up on me at the end. For Delaware (which I tried just because it’s smaller and everything happens faster) the container runs and I can query it with a curl request to localhost.

I’m running this on a MacBook pro with Intel i9 8 cores with 16MB of ram. I have experimented with changing the -Xms7g -Xmx14g part of the run command quite a bit.

Thanks for reading if you got this far and for any help.

I saw a memory error and it was a setting on how much memory Docker was allowed. It was set to 8gigs. I bumped that to 16gigs, which as as far as I can put it on my machine and still got memory errors. I would have thought it would still run (the opb file is ~10gigs) and maybe it should be and it’s something else, but I’m going to find a way to try it on a machine with more RAM.

Had a similar issue. Try setting -Xms7g -Xmx14g to something like -Xms20g -Xmx22g if that doesn’t work, then maybe your machine cant run it. I know I had to upgrade to 32gb because of the same issue.

I have run this on another machine with 48 gigs of RAM now. In this case I set -Xms20g -Xmx40g. It took over 9 hours to run (build the graphs mostly I think) and I got

“error”: {
“code”: 6099,
“message”: “Unable to find an appropriate routing profile.”

I have played around with the Xms and Xmx numbers quite a bit, though it’s hard to make too many changes when it takes hours to see if it worked.

I’m going to keep trying - so any other suggestions will be appreciated. Thanks.

From the error message, it sounds like you were sending your request with a wrong profile name. In the log output above, there is only a car profile activated. For the car profile, the right name would be driving-car if you haven’t changed the name in your config settings.

I did get this working. Tried lots of things, so I can’t say off hand what all the problems were, but the main thing was throwing memory at it. I got this running on an aws fargate server with 48g of RAM and had to make sure the aws settings allowed for a container with enough memory.

I had smaller regions working locally and when I tried running the whole US I could see memory errors even with 16g of RAM. The image is 10g. I had it running on a Linode machine at 48g too, but it failed with (I think it was) 24g. So, shrug, but I don’t know if even doubling the image size (recommended) is always good enough.