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.