Hello, I just set up a planet DB on my server, following the switch2osm tutorial (https://switch2osm.org/manually-building-a-tile-server-18-04-lts). I'm using the default openstreetmap-carto style. Tiles rendering is way too slow to be usable: I plan to pre-render up to zoom 12, and generating a single metatile at zoom 13 takes 20 seconds. It still takes 6 seconds at zoom 16. Here's what I've done so far to speed things up:
What more should I do? I added below more information about my setup. Interestingly rendering durations with render_list seems fine (see below). Here's my server's config:
I imported the planet.pbf file using this command:
It took 36 hours to complete, creating a DB of around 900 GB. Here's what I added to my postgresql.conf:
I also changed my cpufreq-set with the following command:
Here are some rendering durations I got with render_list. They seem fine to me:
What more can I do? Are we supposed to create other indexes than the ones listed in the indexes.sql script? I was expecting rendering performance to be something like 1-5 secs on that server (depending on the zoom level). Is that realistic? asked 20 Aug '18, 17:15 timautin
showing 5 of 8
show 3 more comments
|
I have an oldish import of Europe and I also experience big slowdowns. Importing does not take so long; last time it was a ~16TiB .pfb file that loaded in a couple of days (256TiB consumer grade SSD, 16GiB of RAM, not much tweaking on the PG side). I do think that any performance test should be done with a big import, otherwise the penalties for continent/world levels aren't really felt. Current planet is at 41GiB, Europe 18GiB, N.America/Asia 7GiB, maybe something at least 1GiB? answered 22 Aug '18, 22:42 Marcos Dione |
Did you add indexes to your database?
https://github.com/gravitystorm/openstreetmap-carto/blob/master/indexes.sql
Low zoom tiles are slow to render anyway because of reading a lot of data, but that's probably too long.
Thanks for your comment. As said in my question yes, I executed the indexes.sql script (it was taking half an hour before doing so). Yes it seems too slow to me. It should take less than a second at zoom 16, right?
Sorry TL;DR...
It's hard to say for me, because my render_speedtest numbers were taken with just one country in the database:
https://github.com/gravitystorm/openstreetmap-carto/issues/1287#issuecomment-383266123
Thanks, I'm running the test. Stuck at zoom 0 at the moment -_- ... It was very fast for a small extract (I did test with Azerbaidjan & Corsica extracts, I was under the second all the time). I'm wondering if everything is indeed on the SSD, maybe some indexes are on the default partition, I need to find a way to check that.
I think that without whole planet loaded it's kind of dry run test, because probably it renders empty places most of the time. But it's just a wild guess. Anyway, even dry run data can be usable in a limited way.
Well it's still stuck at zoom 0, I gave up. But the numbers you got seems good, I'd like to get the same. I moved the whole DB on the SSD (previously I was only using a table space), it didn't change anything.
Might be worth noting that my cores are never at 100% (5-20%), and my RAM usage is always low (10GB out of my 64GB).
I have an oldish import of Europe and I also experience big slowdowns. Importing does not take so long; last time it was a ~16TiB .pfb file that loaded in a couple of days (256TiB consumer grade SSD, 16GiB of RAM, not much tweaking on the PG side).
I do think that any performance test should be done with a big import, otherwise the penalties for continent/world levels aren't really felt. Current planet is at 41GiB, Europe 18GiB, N.America/Asia 7GiB, maybe something at least 1GiB?