Unable to Create Profile Graphs for Large (> 1GB) pbfs

Long-term I am trying to build HGV profiles for North America with an extend range. I’ve run into memory errors and have been trying to figure out the problem starting with the examples included in the repo. I’m doing this on AWS and also have to install docker-compose. So initial set-up looks like this

# Install docker-compose
sudo curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
sudo chmod +x /usr/local/bin/docker-compose

# Clone ORS
git clone https://github.com/GIScience/openrouteservice.git && cd openrouteservice

# Download US Northeast
curl https://download.geofabrik.de/north-america/us-northeast-latest.osm.pbf --output openrouteservice/src/main/files/osm_data.osm.pbf

I change ors-config-sample.json to uncomment the build vars so that it looks like this (also increasing -Xmx to 30g, much larger than what should be needed for this region)

version: '2.4'
services:
  ors-app:
    container_name: ors-app
    ports:
      - 8080:8080
      - 9001:9001
    image: openrouteservice/openrouteservice:latest
    build:
      context: ../
      args:
        ORS_CONFIG: ./openrouteservice/src/main/resources/ors-config-sample.json
        OSM_FILE: ./openrouteservice/src/main/files/osm_data.osm.pbf
    user: "${ORS_UID:-0}:${ORS_GID:-0}"
    volumes:
      - ./graphs:/ors-core/data/graphs
      - ./elevation_cache:/ors-core/data/elevation_cache
      - ./logs/ors:/var/log/ors
      - ./logs/tomcat:/usr/local/tomcat/logs
      - ./conf:/ors-conf
      #- ./your_osm.pbf:/ors-core/data/osm_file.pbf
    environment:
      - BUILD_GRAPHS=False  # Forces the container to rebuild the graphs, e.g. when PBF is changed
      - "JAVA_OPTS=-Djava.awt.headless=true -server -XX:TargetSurvivorRatio=75 -XX:SurvivorRatio=64 -XX:MaxTenuringThreshold=3 -XX:+UseG1GC -XX:+ScavengeBeforeFullGC -XX:ParallelGCThreads=4 -Xms1g -Xmx30g"
      - "CATALINA_OPTS=-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9001 -Dcom.sun.management.jmxremote.rmi.port=9001 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djava.rmi.server.hostname=localhost"

The build goes smoothly on the included data, and also goes smoothly if I use small US Pacific region, but when I switch to the larger US Northeast region it I get the errors described below. This error also occurs when I try US Midwest or North America. The Way id changes, but the index does not

2022-01-20 18:55:57,643 INFO [routing.RoutingProfileManager] -  Total - 1.21 GB, Free - 858.96 MB, Max: 30 GB, Used - 381.04 MB
2022-01-20 18:55:57,643 INFO [routing.RoutingProfileManager] -       
2022-01-20 18:55:57,658 INFO [routing.RoutingProfileManager] - ====> Initializing profiles from 'data/osm_file.pbf' (1 threads) ...
2022-01-20 18:55:57,658 INFO [routing.RoutingProfileManager] -                               
2022-01-20 18:55:57,660 INFO [routing.RoutingProfileManager] -                
2022-01-20 18:55:57,686 INFO [routing.RoutingProfile] - [1] Profiles: 'driving-car', location: 'data/graphs/car'.
2022-01-20 19:02:12,232 WARN [extensions.ORSOSMReader] - Index 1048576 out of bounds for length 1048576. Way id = 8003883

I’ve tried to update docker-compose.yml so that JAVA_OPTS includes -Xss10m (and other sizes), but I still get the same error when the graphs start to get build which seems to indicate that the thread is still at a maximum of 1M. This is somewhat confirmed when I tried to set -XX:ThreadStackSize=10m and get and error that threads cannot be set above 1048576.

I have confirmed that JAVA_OPTS are getting passed through to tomcat setenv.sh script after finding some information in this issue. Also it seems like -Xss is getting pased through to the build. When I experimented with -Xss500m and dropped into bash in the running container I found:

> jinfo -flag ThreadStackSize $(pidof java)
-XX:ThreadStackSize=512000

Is there a setting somewhere that overrides the maximum threadstacksize set at 1M?

Fixed in #1183.