So, I was reviewing the performance graphs for the past month using munin, attempting to trace down why we suddenly got such a huge number of waiting tilesets all the time...
and looking at http://munin.openstreetmap.org/openstreetmap/tah.openstreetmap-tah_bytes.html , the number of actual bytes processed has dropped that much (with the exception of earlier this week, hich seems clearly to be a case of just lots of blank tiles in tilesets.). You can see a clear change in behavior in the queue length graph: http://munin.openstreetmap.org/openstreetmap/tah.openstreetmap-tah_queue.html But there is no significant change in the number of tilesets coming in, nor in the number of bytes being processed... The only thing i can figure is that the average tileset size has changed significantly. Oh, actually, there's a second explanation which I hadn't thought of which seems more likely: there's far more tilesets coming in which are *not* coming in through the request management mechanism. I don't know much about the current state of things: can someone who does know what is going on in the 'lowzoom' world comment on whether some significant change in processing might have happened about 3 weeks ago? Given the 'gaps' I'm seeing here, some external process filling up the tileset queue does seem a likely (or at least possible) explanation that I hadn't thought of until just now. Regars, -- Christopher Schmidt MetaCarta _______________________________________________ Tilesathome mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/tilesathome
