Slow rendering with base OSM-Bright style

Question

Hi,

I've installed my own tileserver and imported the whole France to test (the goal being to serve the entire planet). But the rendering is VERY VERY slow, like even for zoom 12 tiles it takes sometimes over than one minute to render (and I'm the only one on the server, so one minute to render a few zoom 12 tiles, it is really slow). I really don't know why it takes so long, I've followed the instructions on switch2osm, the only difference being that I choosed to use the OSM-Bright theme, customized for my needs. But to be sure it wasn't my custom style which impacted the perfs, I've also tried with the original OSM-Bright and it is the same rendering time.

Here is my configuration:

Intel Xeon E3-1245v2 (4c / 8t - 3,4GHz)
32GB DDR3 1333MHz
SSD
apache/mod_tile/postgresql running in docker container

I've imported the data with this osm2pgsql command:

osm2pgsql -d gis --create --slim -G --hstore --hstore-match-only -C 4000 --number-processes 8 -S custom.style --flat-nodes /path/to/flat_nodes.bin data.osm.pbf

But I've also tried without my custom style and without flat-nodes, it doesn't make any relevant difference. While monitoring the server process and ram usage, I've noticed that it was postgresql and not renderd which was taking a long time, and using all process cores at there maximum (which make sense because from what I understood, the postgresql queries are the slowest part of the process).

Following the small tutorial of Paul Norman, I've logged theses queries, returning over and over (the log file is almost only composed of queries like theses ones):

SELECT ST_XMin(ext),ST_YMin(ext),ST_XMax(ext),ST_YMax(ext) FROM (SELECT ST_Extent(way) as ext from planet_osm_polygon) as tmp
SELECT ST_XMin(ext),ST_YMin(ext),ST_XMax(ext),ST_YMax(ext) FROM (SELECT ST_Extent(way) as ext from planet_osm_line) as tmp

With an average time of 1/2secs by queries, so it's probably what slows down the process.

For the record, I haven't enable update yet, so the only queries running are the ones I use for testing rendering. Also, I've tried multiple postgresql confs (following again Paul Newman and Frederik Ramm recommandations), but haven't noticed any big improvment (the time being actually around 1 minute for a zoom 12, I expect it to be closer to a second at this level, am I wrong?).

For higher zoom levels, it become faster (but still a bit slow I think):

z16 : 1.5s
z15 : 2.7s
z14 : 6.2s

Does anybody have any idea of why even with the basic OSM-Bright style and this specs I'm facing this very slow rendering time? It doesn't make any sense to me...

Thanks!

Answer 1

2

Lower zoom tiles tend to be slower as there is much more data per tile / meta-tile to retrieve (from the database) and render (this is naturally offset by zoom dependent style changes), think a factor of 4 per zoom level. It is normal to pre-render at least to level 12 for this reason as SomeoneElse has already pointed out.

permanent link

answered 07 Aug '18, 11:18

SimonPoole ♦
44.7k●13●326●701
accept rate: 18%

Thanks for your answer. Yes I know that and as I just sayed to SomeoneElse, we intend to pre-render those tiles. So for you, more than one minute at zoom 12 is normal? I don't know much about rendering so maybe I panic for no reason... I've added some rendering times for higher zooms, it's way faster but still not acceptable for a production server...

(07 Aug '18, 11:28) voharunado

Answer 2

1

The SELECT ST_XMin... queries should only happen when the renderd worker process starts up, not for every tile. Can you look into that a little more - is there maybe an issue with your setup that causes renderd children to exit after rendering one tile so that you get loads of these queries?

permanent link

answered 07 Aug '18, 12:24

Frederik Ramm ♦
82.5k●92●720●1273
accept rate: 23%

Thanks a lot Frederik, I didn't know that, but it make sense because when a launch render_list, it seems to process way faster than from an apache request, probably because the process isn't killed with that. It may be linked to my docker installation, I'll investigate on this.

(07 Aug '18, 13:50) voharunado

Where should I look to see if the children are killed? Or even when it is fully started? I'm watchning the process list with htop but I can't see any new child process related to renderd, I see some postgres children spawning but that's it.

However I've noticed something strange, after some queries, it become faster (still slow but optimizable slow, like 15 seconds for a zoom 12 tile which is way better than the previous time) and I don't see the SELECT ST_XMin queries anymore... Looks like it's random to me, I've reproduced that twice but it didn't append at the same amount of queries/time...

(07 Aug '18, 14:54) voharunado

Well the problem is really only for the first tiles, so it may be normal I don't know... You said that these queries should only happen at renderd startup but how long does this startup takes? Because I see in renderd log that it is started like 2/3 seconds after I launched it. It takes a very long time (and log the above psql requests, but only when I request some tiles, it does not launch the requests alone at startup) only for the first tiles rendered, but I can't see any logic here... Sometimes it's the first 20, sometimes more (in time, it can take more than 10 minutes of manual requests). But anyway, after a certain number, these requests stops and it starts to be fast...

Not really a big issue if this is just at the server startup, but still, is this the normal behavior? Thanks.

(08 Aug '18, 10:37) voharunado

Did you find a solution in the end? Did you just need to wait? If so, how much time? And what rendering speed did you get? Thanks

(20 Aug '18, 16:34) timautin

Answer 3

I've successfully imported the whole planet but now I'm still having the slow rendering issue. I'm just trying to load one tile after the server just started, and I'm seeing the requests Frederik told me before that it was normal at the renderd start:

SELECT ST_XMin(ext),ST_YMin(ext),ST_XMax(ext),ST_YMax(ext) FROM (SELECT ST_Extent(way) as ext from planet_osm_polygon) as tmp

This one * 5 when I'm looking in pg_stat_activity. And it seems to never go further, I've checked 20 minutes after and there was the sames queries (and only these), but with a more recent query_start and a different pid, to it's like the queries ended, and were restarted... But I really don't understand why, or even what they're supposed to do.

In the renderd logs, I see that when the rendering start:

renderd[21]: DEBUG: Got incoming connection, fd 6, number 1
renderd[21]: DEBUG: Got incoming request with protocol version 2
renderd[21]: DEBUG: Got command RenderPrio fd(6) xml(fr), z(10), x(530), y(367), mime(image/png), options()
renderd[21]: DEBUG: START TILE fr 10 528-535 360-367, new metatile
renderd[21]: Rendering projected coordinates 10 528 360 -> 626172.135713|5635549.221413 939258.203569|5948635.289269 to a 8 x 8 tile
renderd[21]: DEBUG: Connection 0, fd 6 closed, now 0 left

But after that, nothing. Nothing in the postgresql logs either.

Does somebody have an idea of what could cause that?

Thanks!

EDIT: After almost an hour (yeaaah) the tile was done:

renderd[21]: DEBUG: DONE TILE fr 10 528-535 360-367 in 3193.842 seconds
debug: Creating and writing a metatile to /var/lib/mod_tile/fr/10/0/0/33/22/8.meta

But then I started another (random) tile at zoom 16, which should be fast... It was a few minutes ago, I'm still waiting... And I'm still seeing the same requests in pg_stat_activity.

Slow rendering with base OSM-Bright style

Follow this question

Related questions