Graphhopper memory optimization for processing planet.osm.pbf in Kubernetes environment with turn_costs enabled

Developers
1

Hi everyone! We’re experiencing some challenges processing the complete planet.osm.pbf file in our Kubernetes environment, especially considering we’re using turn_costs in our configuration, and would appreciate some guidance.

Current Setup:

  • Graphhopper version: 9.1
  • Environment: Kubernetes (GKE)
  • Node resources: 30 CPU cores, ~236GB RAM
  • Input: Complete planet.osm.pbf file
  • Java settings: -Xmx170g -Xms60g -XX:+UseG1GC

Specific Configurations:

# Java Settings
env:
  - name: JAVA_OPTS
    value: -Xmx170g -Xms60g -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+HeapDumpOnOutOfMemoryError
  - name: GRAPHHOPPER_MEMORY_MAP_DATAACCESS
    value: "true"
  - name: GRAPHHOPPER_GRAPH_DATAACCESS
    value: "RAM_STORE"

# Profile Configurations with Turn Costs
profiles:
  - name: car
    turn_costs:
      vehicle_types: [ motorcar, motor_vehicle ]
      u_turn_costs: 120
  - name: truck
    weighting: custom
    turn_costs:
      vehicle_types: [ hgv ]
      u_turn_costs: 120

The Problem: We’re trying to process the complete planet.osm.pbf file, but we’re facing significant challenges. Besides memory issues (initially getting OOMKilled errors), we’ve noticed that using turn_costs is considerably impacting processing time and resource consumption. After adjusting memory settings, the process starts but still takes an extremely long time and occasionally fails.

Questions:

  1. Are our Java memory settings optimized for processing the complete planet file considering the use of turn_costs?
  2. What’s the expected impact of turn_costs on memory consumption and processing time?
  3. Are there specific recommended configurations to optimize processing when using turn_costs?
  4. Would you recommend splitting the processing into regions? If so, what would be a good approach while maintaining turn_costs functionality?
  5. What are the recommended minimum hardware requirements for processing the complete planet file with turn_costs enabled?

We’re particularly interested in understanding how to balance the use of turn_costs (which is essential for our application) with efficient planet file processing. Any experience or tips on how to optimize this specific scenario would be highly valuable.

Thank you in advance for your help!

2

I cannot comment on your very specific questions, rather generic statements.

Kubernetes is not really suited for running Graphhopper planet processing. The overall idea of Kubernetes pods is to be stateless and a pod can be replaced on the spot by a different one. GH processing takes a lot of time and you really would like to reuse the result for the next startup to save the time importing. You will like something to persist, but than kubernetes starts making fun.

We solved the issue by running Graphhopper Processing in Batch Processing without the scope of K18s persisting the results in an Object Store. On the plus side the GH process working on the result can (at least on our setup) be run on much smaller machines with regards to RAM. But it was even to large to be run in our K18s environment. A conventional Loadbalanced setup is much more suitable for this server setup.

Regarding splitting the planet: Splitting is easy, but if you need to have routing beyond the splits you will run into issues, since GH doesn’t support that (Or we missed some recent development).

Regardings HW requirements, that really depends on your specifc setup and expectations regarding response times and client numbers. Regarding the RAM sizing for processing depends very much on specific configurations (number profiles, routing options, optimizations like LM) . So you are on your own finding out what you need. And btw. other important parameters are the JVM version being used and the userspace process setup.