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<[email protected]>:
>>> 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&refresh=0
>> 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
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/maps-l


_______________________________________________
Maps-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/maps-l

Reply via email to