Am 03.11.2010 08:24, schrieb Kay Drangmeister:

The "dirty" queue is pretty long.

It is so long because the whole tiles at z11 were expired last sunday (will be expired again each Sunday) and just after that, on the first of November, z7-9 was expired (will be expired again on each 1. of a month)

The ~2900 tiles at prio 25 are the bulk rendering of the z0-6 tiles that is started each 1. of a month.

Then another event crashed in: the announcement of the b/w layer.

Those expire- and re-render rules are target of optimizations and if the server can't handle it all, they will be changed or paused or sth.

Is the "lower priority" queue handled at all while the high prio is not done yet (e.g. "at 10% power")?

No, the requests are strictly started in order of priority and age, but running requests won't be terminated, so there may be well running jobs at prio 2 even when we have tiles in the prio 1 queue.

Peter

Am 10.11.2010 09:23, schrieb Thomas Ineichen:

Are there any plans for optimising? Perhaps some indexes on often used tags in hstore? Or another rendering strategy (like Kay suggested [i.e. always use 10% for 'background'])?

There is already an index on hstore, it may help to put indexes on the regular columns that are used by the osm style, but in the problematic zone (z11-z12) only the geom index is used.

We changed the expire process to expire z12 only once a week -- not on every change. This should stabilize the queue and let the server catch up ad night. It may take one or two days until we see results of this.

After that, I'll update the two changed styles.

Peter

Am 10.11.2010 10:55, schrieb Kay Drangmeister:

Hi,

Peter Körner schrieb:

...

We changed the expire process to expire z12 only once a week -- not on every change.

As a related note, I have a tile http://c.www.toolserver.org/tiles/bw-mapnik/10/548/334.png that I tried to .../dirty for days (weeks) now, but it does not get re-rendered (it should be purely black/white). The "colored water" is still an artifact from the first setup. The area in question is here: http://toolserver.org/~osm/styles/?zoom=10&lat=52.80602&lon=12.9021&...

/dirty tiles are added to the queue at prio 10, tiles marked as dirty due to changes on the database are added as prio 2, missing tiles are prio 1.

When you look at the munin graph you'll see, that tirex did not get to rendering the prio 10 tiles because the prio 2 queue fills up too fast.

http://munin.toolserver.org/OSM/ptolemy/tirex_status_queued_requests.html

Your /dirty request is one of the blue ones.

I thought abut changing the prios (missing = 1, /dirty = 5, dirty-on-change = 10) but didn't get to this. I hope that tirex will empty its queues this night due to the change of the expire-on-change configuration, so your tile will get rendered then.

Peter

On Wed, Nov 10, 2010 at 1:46 PM, Tim Alder tim.alder@s2002.tu-chemnitz.dewrote:

Hello, can one part of the performance problem be, that default style is rendering e.g. buildings in z=12? Ok, I can see extrem large buildings like the terminal from airport Berlin-Tempelhof in this zoom-level but the most buildings have subpixel dimensions. So perhaps somebody is interested in style optimisation. Especially with a view to what Wikipedia really needs, so IMO we could live without "amenity=recycling"...

Yes, we need a modified OSM style that's suited more for Wikipedia. I'm working on styles that do things like render buildings=yes + tourism=attraction at lower-medium zoom levels, but render all buildings when zooming in more.

Also, we are using OSM style from some months ago. It's rendering things like parking in a non-ideal way, but has been improved some in the OSM style since. Is this something that I could help with?

-Katie (@aude)

PS - I'm really happy to see OSM in German Wikipedia and willing to put more time in to help (if needed) with getting it into English Wikipedia as a gadget, to start with.

Greetings Kolossos

---

Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l