[OSM-dev] Various OSM troubles

Ludwig Max Brinckmann ludwigbrinckmann at gmail.com
Tue Jan 9 11:11:35 GMT 2007


Could someone enlighten us to what runs on what machines?

It looks like all the DB work is happening on dev.openstreetmap (
http://www.openstreetmap.org/munin/openstreetmap/dev.openstreetmap.html#Mysql),
while db.openstreetmap is somehow generating lots of cache lookups without
any associated SQL ops
(
http://www.openstreetmap.org/munin/openstreetmap/db.openstreetmap.html#Mysql),
which somehow cannot be right.

Would it be possible to get some stats on the REST API, particularly those
calls that fail? It would be interesting to see if it is possible to
identify those queries that have a large likelyhood of failing.

Ludwig



On 1/9/07, Andy Robinson <Andy_J_Robinson at blueyonder.co.uk> wrote:
>
> Dave wrote:
> >Sent: 09 January 2007 9:55 AM
> >To: Joerg Ostertag (OSM Munich/Germany)
> >Cc: dev at openstreetmap.org
> >Subject: Re: [OSM-dev] Various OSM troubles
> >
> >Joerg Ostertag (OSM Munich/Germany) wrote:
> >> Currently I don't think the bandwidth for downloading is the problem,
> but
> >the
> >> sql-query takes all the resources. So doing a diff probably only
> doubles
> >the
> >> needed db-resources.
> >>
> >>
> >>> Imagine I keep my osm data locally. If JOSM starts, it loads that data
> >>> file and then asks the server to deliver *only* the data that has
> >>> changed since the last sync. This at least would save a lot of
> >>> bandwidth, wouldn't it? This even is valid for the future as the user
> >>> base grows.
> >>>
> >>
> >> This was something imi already suggested some times. He suggested
> writing
> >a
> >> local caching OSM-Server which starts with the current planet.osm and
> >then
> >> only get the updates. If the central OSM-Database is fast enough this
> >> probably would really speed up things on the local machine. But we have
> >to be
> >> even more carefull with handling editing conflicts.
> >>
> >If bandwidth isn't really a problem, and we're having DB query time
> >issues, couldn't we just set up some MySQL replication magic and have
> >the API ruby code split data requests between the master and slaves?
> >
> >Of course this implies we have more server hardware to spare... I don't
> >know what the current hardware situation is; typing Servers on the wiki
> >gives lots of nice pictures of people loading racks full of them though
> >-- but no hard data unfortunately. And comments on this list suggest
> >resources are very limited.
> >
>
> A good place to see everything in one place is via the munin page:
> http://www.openstreetmap.org/munin/
>
> Cheers
>
> Andy
>
>
>
> >
> >
> >_______________________________________________
> >dev mailing list
> >dev at openstreetmap.org
> >http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20070109/2e456bbf/attachment.html>


More information about the dev mailing list