Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Slow performance of osrm-extract inside Docker container #1

Open
danpat opened this issue Oct 24, 2016 · 3 comments
Open

Slow performance of osrm-extract inside Docker container #1

danpat opened this issue Oct 24, 2016 · 3 comments

Comments

@danpat
Copy link
Member

danpat commented Oct 24, 2016

When running osrm-extract from inside a docker container, extraction is slower than if performed on the host machine itself, by about 25%.

I can think of a few possibilities:

  1. Something like Slow IO performance inside container compared with the host. moby/moby#21485
  2. Different compiler optimizations inside our docker images (poor optimization?)
  3. Docker overhead (should be 0 in a Linux environment).

STXXL performs lots of I/O during osrm-extract - any overhead from the Docker FS layer here would hurt us.

I have not tested osrm-contract or osrm-routed performance at this stage.

/cc @miccolis

@daniel-j-h
Copy link
Member

@miccolis @danpat any updates on your side here?

We now publish tags and master to https://hub.docker.com/r/osrm/ and in the future we may want to use the Docker images for the demo server.

The linked issue was fixed in Docker 1.12, and was caused by Linux' CFQ scheduler trying to balance I/O between cgroups.

Docker 1.10.3 is in Ubuntu 16.04 but according to issue deadline sched (Ubuntu default) not affected.

@miccolis
Copy link

miccolis commented Mar 27, 2017

One thing that helped was explicitly setting the number of CPUs available to the container. Docker doesn't completely hide info from a container, so if you have a containers that tries to spawn threads for all CPUs there will be contention. Using the --threads argument and setting the OMP_NUM_THREADS & MALLOC_CONF environment variables helped.

@danpat
Copy link
Member Author

danpat commented Apr 6, 2017

@sreeramvuppala You could just make a new Dockerfile that uses the OSRM image as a baselayer:

FROM osrm/osrm-backend:latest
WORKDIR /data

Then, you can put the .stxxl file in the same directory as your .osm.pbf files, outside your container.

sreeramvuppala pushed a commit to sreeramvuppala/osrm-backend-docker that referenced this issue Aug 4, 2017
Updated OSRM references to version 5.0.0 for docker
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants