Hello,

thank you for the information.

On 04/20/2011 01:40 PM, Tim Alder wrote:
> Hello,
> 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.[1]
> (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
> this situation.
>
> *We have enough CPU power but if I look on the I/O-power [2] 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
> this situation.

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 for
> 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 
predict though.
> 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[3]. 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.

Kai
>
> Greetings Kolossos
>
> [1] https://jira.toolserver.org/browse/TS-971
> [2] http://munin.toolserver.org/OSM/ptolemy/index.html#disk
> [3]
> http://lists.openstreetmap.org/pipermail/legal-talk/2011-April/005907.html
>
> _______________________________________________
> Maps-l mailing list
> [email protected]
> https://lists.wikimedia.org/mailman/listinfo/maps-l


_______________________________________________
Maps-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/maps-l

Reply via email to