[OSM-dev] Renderd problems.

Kai Krueger kakrueger at gmail.com
Sat Oct 2 13:28:48 BST 2010

On -10/01/37 20:59, Peter Körner wrote:
> but renderd had a hard limit of 1000 tiles in the queue.

For completeness sake, I thought I'd mention that you can change that 
limit quite easily. Simply change the constant at 
to a higher value and you should be done (well OK, the constant the line 
below also should be adjusted).

That limit used to be there, I think, as the queue used a linear list, 
which meant adding and searching tiles where O(n), thus n was limited. 
It now uses a hashtable lookup, so that limit could be much higher 
without problems.

On the main OSM tile server, I believe, that limit is still there as a 
feature rather than a bug. In order to achieve a fast turn around time 
for mappers, the queue is limited, thus also "limiting" the time a 
request takes to get through the queue. Instead requests are dropped 
completely and the next time someone views the tile, mod_tile again 
tries to queue it. This has the advantage that frequently viewed tiles 
are more likely to end up in the queue and then are quickly rendered.

Ideally, you would probably have a large priority queue with the 
priority boosted every time another request comes in for that tile. But 
that isn't implemented. Does tirex support that?


P.S. Personally, I think the trade off of 1000 metatiles is somewhat too 
low, as with 3 - 5 metatiles / s that yevaud manages, the queue's turn 
around time is usually less than 10 - 20 minutes (if it only renders 
queued tiles and not on the fly, it is more like only 5 minutes), 
whereas the dropped render request means that some of the less 
frequently viewed areas might be quite out of date or inconsistent. 
However, as with all heuristics and trade-offs, it is hard to judge were 
the actual sweet spot is, and it is not really possible to measure it 
either. So 1000 metatiles might well be a good compromise. Also on 
servers, that can't keep up with rendering demand, even at low traffic 
times during the night, that limit is likely to be particularly 
important to prioritise.

More information about the dev mailing list