The new container image has a lot of improvements to stability and performance so that it can be used reliably over the long term. It also has improvements to make it easier to set up Overpass and get started with it.
Has anyone tried to run this with attic support? I have started the image as per instructions, using the “download clone” path with --meta=attic, and it has downloaded the data ok, but when I then start the thing (with OVERPASS_DIFF_URL=https://planet.openstreetmap.org/replication/minute/), about half an hour in it stops with
2026-06-13 00:02:35: ERROR: Health check failed, shutting down
and the apply_osc_to_db.out says
Compute current ... ready.
Flushing to database ......done.
Compute attic ...
Way 367184395 has changed at timestamp 2023-03-13T04:56:52Z in two different diffs.
Way 864039068 has changed at timestamp 2026-06-03T00:00:08Z in two different diffs.
terminate called after throwing an instance of 'std::length_error'
what(): vector::reserve
/opt/overpass/bin/apply_osc_to_db.sh: line 530: 138821 Aborted (core dumped) ./update_from_dir --osc-dir="$OSC_DIR" --version="$DATA_VERSION" ${META:+"$META"} --flush-size=0
Is it possible that the attic-supporting clone is somehow corrupt, or what could be the problem here?
I have run the container with attic data, so it should be fine. The errors you got are from the underlying C++ code internal to Overpass, which really hasn’t changed in the container build.
I suppose it’s possible that the database clone with attic data is corrupt. The other possibility is a resource limitation affecting your container instance. Are you sure it has plenty of memory?
For what it’s worth, the messages about the ways changed at the same timestamp in two different diffs are normal operational messages. When Overpass computes attic data, it stores a chronologically consistent set of element data and skips element versions that are out of chronological sequence. Odd, but that’s the way it works.
It’s actually relatively common for clone downloads to fail due to transient network issues. You might try redownloading the database files and double-checking the download logs to make sure everything came in correctly.
If you’re using the container’s download_clone.sh script, you can restart it after a failure and it will pick up where it left off.
I have re-run the whole process including download from scratch, and received the same error message. Perhaps it is something to do with how diffs are combined into chunks to be applied?The machine has 128 GB of RAM which is plenty for a non-attic overpass but I have no experience running it with attic. I am now waiting for a new clone to appear on the dev server, maybe that magically fixes things…
I just built a new container with the current database clone including attic data and it’s working fine. However, I disabled area generation at startup.
There’s an issue in the current container build with area generation and database updates at first launch. When you download the database clone, it will be behind the current replication, likely by several hours. That means that several batches of updates need to be processed to get the database in sync with replication. And, when you start the container with area generation on, the area generation process starts immediately and locks the database, preventing updates.
That causes some issues. There’s a patch in the b1tw153/docker branch that correctly pauses the database updates while the first area generation runs. But I’ll be implementing a better solution soon.
The immediate workaround is to start the container without area generation, allow it to catch up with replication, then stop and restart with area generation turned on.
It took a little while but my container ended up with the same error as yours at exactly the same place, batch 7142469 to 7143316. And I have the same error in apply_osc_to_db.out:
Compute current ... ready. Flushing to database ....... done. Compute attic ...Way 367184395 has changed at timestamp 2023-03-13T04:56:52Z in two different diffs.
Way 864039068 has changed at timestamp 2026-06-03T00:00:08Z in two different diffs.
terminate called after throwing an instance of 'std::length_error'
what(): vector::reserve
/opt/overpass/bin/apply_osc_to_db.sh: line 530: 198102 Aborted (core dumped) ./update_from_dir --osc-dir="$OSC_DIR" --version="$DATA_VERSION" ${META:+"$META"} --flush-size=0
I’ll try running the original executables on bare metal to confirm, but this looks like a problem with the database clone files or a bug in the original source code, or both.
Assuming it’s a problem in the database clone files, you could try starting with a PBF import to build the database from scratch. That can take a long time, though.
Thank you for taking the time, it helps to know that one is not alone with an issue ;) I see that a new set of clone files is currently being prepared on the Overpass dev server; with any luck the problem will be gone using those. Fingers crossed!
Database corruption is a real issue with Overpass. It happens any time the processes are interrupted while updating the database, which is a substantial portion of the time. So, any time there’s a disorderly shutdown there’s a real chance the database will be trashed.
I’ve dealt with it a lot, which is what prompted most of the changes in my container build. Even then, I can only reduce the risk, not eliminate it.
I don’t know what happened, but I would guess that may have been the cause of the corruption in the 2026-06-06 clone.
I’m already running my own overpass instance, and it is working fine at 1 request per second. I need more though, and if I push more, the response time quickly climbs. I’m running it in AWS ECS/EFS. I can’t tell where the bottle neck is. Perhaps EFS latency.
Anyway, I will try this new branch. If you have any tips on performance tweaking, I’m all ears.
If you’re running in ECS/EFS, file system throughput is likely the biggest bottleneck. Overpass moves a lot of data around, so throughput generally matters more than latency. Whatever you can do to improve file system throughput is going to pay off.
In general, tuning Overpass is a matter of getting the fastest file system performance you can. If the file system is fast enough, you can run up to one concurrent query per CPU. Then you just need to make sure you have enough RAM to leave some headroom at peak load – how much RAM depends on what your queries are loading.
I mentioned latency instead of throughput, because if it were hitting throughput limits, I’d expect to see it hit the hardline in Cloudwatch metrics. In other circumstances, this usually stands out pretty clearly. I will investigate this more though - you’re probably right.
I’m only running a single city, so it should be able to keep much of the dataset in memory. Can I configure it to cache more in memory, or anything like that?
There is no caching in Overpass. Each query runs as its own process and releases its resources when it completes. However, the queries do go through the OS pager, and the OS can store file system data in its page cache.
If you have memory to spare but the file system is slow, you should see a performance improvement as the OS caches more data. For a single city extract, it’s possible you could get the OS to cache the entire database.
Let me know what you find when you look deeper into resource usage!