Am 29.08.2011 16:40, schrieb Kai Krueger:
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?
Hello, my theory is that we started with rendering around Alaska.
This area is relative empty and stretched by mercator-projection.
Now we are somewhere in Canada/USA incl. NYC with high density of
geo-objects.
Following the z-curve we should come back to empty areas in the north
several times, and render again very fast. If not, my theory is false.
In general:
Tirex should be able to order the queue by z-curve, especially if you
have more than one style (not sure how it can reach the end of it), it
would makes it for me much easier to handle it. And Tirex should be able
to not order the queue.
> 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).
I change the parameter to 4 in
~/tirex/lib/vendor_perl/5.12/Tirex/Source/ModTile.pm
It seems that it need a restart of tirex, what I don't want to do in the
moment.
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.
No idea where to do this.
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?
Would be important to know. It seems to work at beginning.
