On 08/29/2011 02:22 AM, Peter Körner wrote:
Am 27.08.2011 23:31, schrieb Kay Drangmeister:
Hi,
Am 27.08.2011, 23:11 Uhr, schrieb Tim Aldertim.alder@s2002.tu-chemnitz.de:
Hello, we have now an up-to-date database, and expiring is working again.
Looks great. http://toolserver.org/~mazder/tirex-status/?short=1&extended=0&refre... shows a new queue "systema", I guess that's exactly it.
One observation: currently putting re-rendered tiles into the queue is a bit quicker than the queue rendering tiles, so the queue grows slowly over time. Nothing to worry I guess, tho'. But: should the AGE of the tiles not gradually decrease, as the queue is supposed to render oldest tiles first?
The queue is sorted by the number of requests received for this tile, not by age.
Will this not quickly mess up the systematic ordering of the systema queue? Is it possible to turn off this reordering?
Has this got something to do with that throughput has dropped from 160 - 200 down to (still better than before) 60 - 70 tiles / minute? But overall, it does seem the systematicity is working.
And is "dirty" now separate from the "systema" queue (as is apparent)? If I try to manually dirty a metatile, I don't see it appearing anywhere on the page linked above.
when tirex receives a dirty message from mod_tile (metatile oder then planet-timestamp), it enqueues it with prio 2, so it's put into the systema bucket. This can be changed in source [1] (i guess the second int in the array is the priority for cmdRender).
Perhaps the mappings from mod_tile render request types to tirex priority levels could be made configurable.
Alternatively, one could tune the mod_tile config to send requests as cmdDirty rather than cmdRender (the latter assumes the request can be rendered on the fly, which isn't the case if about 300k tiles are ahead of it in the queue) mod_tiles cmdDirty maps onto tirex prio level 10 by default.
Kai
P.S. In the run.log file, at the end of each import, there are messages of the form
26799 import done [2011-08-29 02:11:54] 26799 expiring tiles [2011-08-29 02:11:54] 26799 [error] tile_expiry error [2011-08-29 02:11:55] 26799 resetting state
Does the "resetting state" have anything to do with that the replag is not going down?
Also, if you enqueue a tile that is already in one of the queues, it's not added a second time but just moved up a little in the queue.
Peter
[1] http://trac.openstreetmap.org/browser/applications/utils/tirex/lib/Tirex/Source/ModTile.pm#L121
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l