-
-
Notifications
You must be signed in to change notification settings - Fork 119
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
[FEATURE] Can pass1 be re-sorted for pass2? #982
Comments
Can you share the exact command you are running and logs? I don't have a windows machine to test on but with Linux pass2 averages 27k ways per second even with 8GB of RAM (https://github.com/onthegomap/planetiler/blob/main/planet-logs/v0.7.0-planet-im4gn-8gb-no-z13-building-merge.txt) so it seems like it should be faster. I'm trying to understand how the sort would work, seems like at some point it would still need to do the random access lookups to join the node locations, we'd just push that lookup to the sort stage. Curious to see the command and logs though, there might be something else going on. |
Would be great if you could reproduce the issue. Win 10 with HDD (not SSD, maybe that's the secret ingredient). canada:
us:
|
OK got it thanks for the info. The HDD is probably the issue here. One workaround would be to use Something like this might work:
The 2 merge sorts and sequential scans should be more HDD-friendly, but that would be a good amount of work and pretty low priority since most people are using an SSD. For now I just updated the README to recommend using SSD but feel free to open a PR or report back if you have bandwidth to prototype and see if it helps on your setup. |
Running |
I am running on Windows, 32GB of RAM.
When generating tiles for say Canada (4GB), the generated node.db is 6GB and the OS auto memory-maps it correctly. During step2_ways I get 100-150k/s, and almost no HD activity.
But for the US (10GB), the generated node.db is 16GB, and for some reason the OS does not like that, during step2_ways processing is 2-5k/s, aka 30x-40x slower, and HD is at 100% usage.
Can node.db (or another copy of it) be pre sorted for the ways step? So the reads will be sequential and avoid the random read penalty?
Perhaps it makes sense to update docs that for good performance 1x-1.6x of RAM is required.
Thanks!
The text was updated successfully, but these errors were encountered: