Cassini used to only assign 24MB of shared memory to PostgreSQL, I changed that to 128MB.
We mostly seemed to be IO-bound on cassini so it looks like this has helped..
Hi guys,
I'm at the New York Public Library right now. They showed me http://maps.nypl.org/warper/ . It's a very cool tool to make overlays of old maps on OSM. It's build using open layers. Maybe we could do something like this for the maps we have at Commons?
Maarten
We already have http://commons.wikimedia.org/wiki/Template:Overlay which allows to supply a KML file to view a map overlay in Google Earth or Google Maps.
On Tue, Apr 20, 2010 at 12:45 PM, Maarten Dammers maarten@mdammers.nl wrote:
Hi guys,
I'm at the New York Public Library right now. They showed me http://maps.nypl.org/warper/ . It's a very cool tool to make overlays of old maps on OSM. It's build using open layers. Maybe we could do something like this for the maps we have at Commons?
Maarten
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
Hello, yes we have Commons:Geocoding/overlay and actually are 104 prepared maps there. But we could need a better editor with a real rectifier and a OpenSource-Viewer like OpenLayers. So feel free to be active in this topic.
Your big advantage is in the moment that we don't need to save the images on an additional place. Not sure how to combine this with a rectifier.
I believe with over 6 Mill. images on Commons in the background we could be better than now and more successfully than http://www.openaerialmap.org in the past.
Greetings Kolossos
Maarten Dammers schrieb:
Hi guys,
I'm at the New York Public Library right now. They showed me http://maps.nypl.org/warper/ . It's a very cool tool to make overlays of old maps on OSM. It's build using open layers. Maybe we could do something like this for the maps we have at Commons?
Maarten
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
On 04/19/2010 05:35 PM, Ævar Arnfjörð Bjarmason wrote:
Cassini used to only assign 24MB of shared memory to PostgreSQL, I changed that to 128MB.
It seems that all of postgresql default memory settings are awfully low for such a big database as mapnik's planet.osm. Even 128Mb may still be too low. Although I don't have any own experience on this, from talking to others, it appears that both the shared_buffers setting as well as the maintanance_work_mem (especially during initial import) should be in the gigabyte range. Unfortunately non of the documentation on the wiki seem to have any good guidelines on setting these values, or example configs available in svn.
Does ptolemy need similar tweaks, or has its config been optimized already?
We mostly seemed to be IO-bound on cassini so it looks like this has helped..
The rendering performance varies quite heavily with the zoom level. For low zoom tiles it doesn't appear to be uncommon to need in the range of tens of seconds to minutes, whereas the the high zoom tiles are typically rendered within the 3 second timeout of mod_tile.
It does appear as if cassini is rendering a disproportionate amount of low zoom tiles. Most of the low zoom tiles I have checked where renderd within the last day or two. How does the expiry work on low zoom tiles?
On the otherhand some of the tiles don't seem to be updating at all. An example is http://cassini.toolserver.org/tiles/osm-like/de/2/1/1.png/status This claims to need rerendering so presumably every time some one views this tile, mod_tile will send a rendering request to renderd for it. However, the rendering never seems successfully completed and thus doesn't clear the "dirty flag". Is it possible that renderd doesn't have permission to write to some of the sub directories? Thus rendering the tiles successfully, using up resources, but not being able to write the results to disk?
It may also be worth updating to the latest version of renderd and mod_tile, where I had added some more munin graphs allowing to see the proportion of zoom_levels for served and rendered tiles. This may allow to see if indeed there is a disproportionate amount of low zoom tiles, which could explain the low performance.
Kai
Maps-l mailing list Maps-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/maps-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Kai Krueger:
[shared_buffers] Does ptolemy need similar tweaks, or has its config been optimized already?
ptolemy's shared_buffers is currently set to 256MB. I experimented with various sizes, from 128M up to around 25G, but I found that a larger setting did not increase performance (in fact, very large settings made it noticeably slower). So, I think 256M is reasonable.
- river.