thank you for the information.
On 04/20/2011 01:40 PM, Tim Alder wrote:
here some things that running absolutely not smooth in my eyes and we
should work on this problems:
*The Expiring/updating process is not running for months.
(To have an up-to-date map is perhaps not so important for wikipedia,
but I hear from some mappers, who use hikebikemap and other maps to
control there changes.)
If I understood Peter's mail from the beginning of March correctly, the
expiry is partially working?
I.e. the touch-mode is working, but not the renderd-mode? As I presume
the touch-mode is used for low-zoom and renderd-mode for low zoom, the
situation shouldn't be too bad.
Mappers tend to use the high zoom levels to check for details and the
low-zoom tend not to have noticeable changes that often anyway. Osm.org
also only does direct tile expiry on high-zoom tiles. One possibility
for a band aid until the expiry is fixed correctly, would be to touch
the db time stamp file. This would expire all tiles and would therefore
add some extra strain on the server for a couple of days, but it would
also allow to rerender tiles for which the style sheet has changed.
*The rendering of the>200 styles for the different
languages make it
difficult to handle the server.
Is that still the memory issue, or did the move to tirex mitigate this?
*We have running now a productive system and
experimental systems on the
same server. This means we can't make in the moment big experiments!
I will be also in Berlin and I hope we can talk about a solution for
*We have enough CPU power but if I look on the I/O-power  it looks
that we are on the end of sd3-reading power. So I'm not sure about the
reason, but I don't believe that we should activate gadget in en.wp in
On nearly all tile servers I have seen so far, the bottleneck has always
been the I/O performance. So it wouldn't be surprising that the read
IOPS of the disks are maxed out. There are two aspects to I/O
performance. For one the postgis access and secondly tile access. With
only ca. 100 tiles/s I wouldn't think the tile access would be a
significant I/O bottleneck. Postgis on the other hand will likely take
all I/O performance it can get as long as there is something to render.
(A upgrade to SSD's would be very interesting
I/O-power. I my eyes we would need only 400 GB so it shouldn't cost too
much if we could speed-up the rendering perhaps by factor 5! This would
also speed-up the other tools which uses the OSM-database. A solution by
brain-power would be off course better.)
You would presumably only want to put the
postgis-DB on an SSD? The
tiles are probably better off on larger but slower disks.
*We have a performance problem for
"full-styles" at medium zoom-levels
so e.g. "black-and-white"-styles running in the moment at zoom-level 10
over 1000 seconds for one meta-tile. That's too long!
So in this moment it wouldn't be a good idea to make advertisement for
new developer to bring more and more map-styles on the server.
With activating the map in english wikipedia I estimate that we could
increase the load on server by factor two. If we make advertisement for
this map the peak on the first day could be higher.
Pure tile serving wouldn't
likely be the issue. A reasonably powerful
server like ptolemy should be able to handle greater than 1000 tiles/s.
Tiles are also well cachable through squid proxies. What the effect on
rendering queues and tile disk usage would be, is probably harder to
So we have a lot to do, especially in the admin area.
And we should talk
more about this problems on this list.
To the legal concerns I give Frederik an answer on legal-talk. That
shouldn't be our biggest problem.
There has been a lot of controversial debate
on the licensing issue
within the OSM community, but I don't think it would have significant
effects for data users like wikipedia. Tile serving is well within the
anticipated use cases for either license. Possibly all that would change
would be a slight change in the attribution string displayed. Tiles (as
produced work) can probably even stay under CC-BY-SA.