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 Alder<tim.alder(a)s2002.tu-chemnitz.de>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&refr…
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(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/maps-l