Hilfe, OSM Rendert plötzlich alles in Baustellenfarbe!!!

(Somit ist die Welt nun auch keine Baustelle, sondern ein riesiges Gebäude. Vermutlich, damit es nicht reinregnet. :P)

Sieht sehr so aus: https://pewu.github.io/osm-history/#/way/450702564

Das Gebäude scheint(!) noch da zu sein.

Danke fürs Raussuchen. Aber warum kann ich es nicht in JOSM einladen?

Danke, whb, fürs Löschen. Wie hast du das gemacht? Mein JOSM weigerte sich, es zu finden. Manuelle .osm-Datei erstellt?

Habe das Gebäude entfernt:
https://www.openstreetmap.org/changeset/43346005
Musste das mit einer manuell erstellten OSM-Datei lösen, da der Server die Daten nicht ausliefert…

Der Server scheint wirklich ernsthafte Probleme zu haben.

Der Fehler ist schon bekannt:

https://wiki.openstreetmap.org/wiki/Platform_Status

Super. Damit scheint das Problem im Rahmen der Möglichkeiten gelöst; die in den letzten drei Stunden neu erstellten Tiles müssen dann wohl nochmal erstellt werden. Armer Tileserver… :-}

Es scheint seit einiger Zeit einen “Read only database mirror” zu geben:
https://hardware.openstreetmap.org/servers/ramoth.openstreetmap.org/
Dieser hat zzt. einen “replication delay” von ca. 8 Stunden:
http://munin.openstreetmap.org/openstreetmap/ramoth.openstreetmap/postgres_replication_9_1_main.html
Das ist zum Mappen natürlich nicht gerade optimal.

Das ist richtig. Dieser Delay scheint seit gestern abend zu bestehen. Pure Raterei: Vielleicht wurden da außergewöhnlich viele (oder komplexe) viele Changesets reingekippt?

Edit: Glaube ich selbst nicht mehr. Wenn dem so wäre, wäre wenigstens ab und zu mal ein Peak nach unten. Vermutlich ist eher der Replication-Prozess down oder fehlerhaft, oder was auch immer.

Weiß jemand, ob es eine Adresse gibt, mit der direkt der Master angefragt wird, um in solchen Fällen aktuellere Daten zu erhalten?

vielleicht auch im Zusammenhang: https://forum.openstreetmap.org/viewtopic.php?pid=615644#p615644?

fragt Sven

Klingt interessant.

Auf ramoth gibt es zur fraglichen Zeit auch eine Spitze in den Netzwerverbindungen: http://munin.openstreetmap.org/openstreetmap/ramoth.openstreetmap/index.html#network . Kann die auch von dem Irland-Grenzproblem kommen?

Ich hab zwar keine Ahnung von diesen Replikationsgeschichten, halte das aber durchaus für denkbar. In Irland wurden ja in kurzer Zeit (in den letzten vier Tagen) massiv Daten verändert… und ich kann mir gut vorstellen, daß da irgendwann die Replikation ausgestiegen ist. So nach dem Motto: ‘Trichter in die Gusche und mit dem Eimer Füttern, ohne Rücksicht darauf, daß das Futter aus den Mundwinkeln bereits wieder rausquillt…’

Eventuell sollte eine Sperre eingebaut werden (Anzahl gleichzeitig hochzuladender Relationen begrenzen), daß dieses Datenbanküberfüttern verhindert wird… Importrichtlinien anpassen…

Sven

Ich ehrlich gesagt nicht, zumindest nicht ob der schieren Datenmenge. Denn die Daten sind ja auf dem Master vorhanden. Und ich kann mir schlecht vorstellen, dass das Replizieren wesentlich länger dauern soll als das Importieren in die Masterdatenbank.

Kann allerdings sein, dass, wenn der Slaverechner wesentlich langsamer ist als der Masterrechner, tatsächlich die Langsamkeit das Problem ist. Aber generell würde ich selbst dann erwarten, dass der Replikationslag langsam, aber stetig abnimmt.

Wäre möglich, aber dass der Import von vorgestern erst gestern abend die OSM-Replikation zerbröselt haben soll, würde mich auch wundern…

Es könnte auch mit der Hausnummernauswertung zu tun haben. Die zieht sich die Daten von Overpass und damit von der Live-Datenbank, und die Auswertung war gestern.

Es gibt noch einen: https://hardware.openstreetmap.org/servers/karm.openstreetmap.org/

Dieser scheint etwas schneller zu sein, hatte aber im Grunde das gleiche Problem wie ramoth jetzt. Und auch bei ramoth geht die Linie grade nach unten. Evtl. geht sie in ein paar Stunden nochmal kurz hoch, um dann irgendwann wieder auf 0 zu gehen.

Vergleiche:

EDIT: falscher Thread

Overpass verarbeitet Minutely Diff Files und hängt nicht direkt an der Live-DB. Was an Last auf dem Overpass-Server anfällt hat genau 0 Auswirkungen auf die Live DB.

Ja, genau der dürfte das gewesen sein. Dass die halbe Welt braun wird (Gebäude, Baustelle, …) passiert gefühlt vier Mal im Jahr. Ende August/Anfang September war es mal ein Gebäude über halb Lateinamerika.

Aus diesem Grund ist jeder Edit, der eine sehr große Bounding-Box hat verdächtig und potentiell gefährlich.

Wer solchen Müll entdeckt, revertiere einfach den betreffenden Änderungssatz und warte dann eine Weile.

Der Delay hatte wohl rein gar nichts mit hoher Last durch irgendwelche Edits zu tun. Vielmehr haben die Admins gestern versucht, einige voellig sinnlos aufgeblaehte indexes auf der datenbank aufzuraeumen (durch Neugenerierung). Das fuehrte dann dazu, dass einige Datenbanktabellen “gelockt” waren bis die Neugenerierung durch war. Die dauerte laenger als gedacht, sie wolltens aber auch nicht mehr abbrechen.
(Quelle = mitgehoert in #osm-dev)

Mittlerweile scheint der replication-delay aber wieder auf 0 zu sein (man sieht recht gut am munin-graphen: sobald der neue index fertig gebaut war, hat die replication sehr schnell ihren rueckstand aufgeholt - die am Ende noch 6 Stunden Rueckstand waren in weniger als 1 Stunde aufgearbeitet)