Hi all, my first post here. I installed a tile server following this https://switch2osm.org/manually-building-a-tile-server-16-04-2-lts/ and managed to get it work ... sort of. I installed leaflet on top of that, and something indeed happens - eventually. When I go to a new location on the map or a new zoom level, I get an empty screen and after 30 seconds (timeout set in apache conf) 404 errors (GET /hot/3/1/3.png HTTP/1.1" 404 503 "http://10.0.0.126/map.html") and so on. (map of the whole world imported). When I do a refresh later or move elsewhere and come back, the tiles are there. I am not too familiar with any of this but my diagnosis is that rendering of tiles just takes "too long". This is unlikely to be a hardware issue as I commandeered an unused server from a server room rack for this. I have 40 cores, 192GB of memory and 6TB of solid state storage. This is a fresh 16.04 server install with nothing else running on it and everything up to date. Ok. Rendering of tiles may be slow, and I thought to speed it up by doing a lot of it beforehand as I do not particularly lack resources here. I tried
but it just hangs. It does not appear to be doing anything. It does not consume any resources whatsoever and it does not cause anything visible in CPU, renderd or postgresql processes. In contrast, when I navigate with my browser to an unvisited area on the map, I can see 6-8 postgresql processes taking 100% of CPU for a while and renderd peaking occasionally as well. Apparently something is not right, but what exactly and how could I debug this? EDIT: This is my renderd.conf:
From syslog I can see successful rendering but the lower the zoom level, the more time it takes. The higher zoom level speeds are completely acceptable, it is just zoom levels 3-5 that seem to take forever:
When I run render_list, I do get a connection reported like this (the only interesting line, no other RenderBulk requests appear):
but then nothing else happens. No other log entries, and no CPU or disk activity whatsoever (I have waited for about an hour for something to happen). Restarting renderd does not produce any interesting log messages (debug messages about fonts mainly). The only "odd" part is this (no function name - not sure if it is ok or not).
EDIT2 If I run render_list as
I sometimes seem to be getting log messages:
But it does not seem to matter from functional perspective if these appear or not. asked 05 Feb '18, 14:35 hv42 aseerel4c26 ♦
showing 5 of 7
show 2 more comments
|
map is ajt -m ajt that works answered 29 Nov '18, 10:42 andreaswoods The original question was asking about slow tile rendering rather than not working at all - I wonder if the "default" in the original quoted render_list command was a typo, or if "default" actually works if there's only one style defined?
(29 Nov '18, 11:13)
SomeoneElse ♦
|
... and it seems to be only the "wide" zooms causing the problem making the above render_list really useful. If I zoom into an obscure location on the planet, those tiles are server quickly. So I guess my question is how can I find out why render_list does not do anything.
What messages do you see in /var/log/syslog ? When a request is made to render a tile such as http://yourserver.example.com/maps/default/0/0/0.png you should see things including lines such as:
"render_list" just sends a series of requests for tiles, so you should see a series of requests.
What's in your "renderd.conf" file? What happens in syslog in response to "sudo /etc/init.d/render restart"?
Thanks for your reply. I have updated the question instead of posting answers here for the sake of readability.
The same problem: render_list does not do anything! No tiles generating.
"the lower the zoom level, the more time it takes" - this is expected behavior. That's why low zoom levels on http://openstreetmap.org/ only get updated from time to time.
@Michael Holopov - it shouldn't "not do anything"; you should see activity in syslog (see the snippets added to the question). You might have to wait minutes or even longer to see tiles at low zoom level, but that's normal.
typically a posgres issue : you have enough memory but did you configured postges to use it ?