Graue Kacheln in OpenStreetMap.com

Wenn /dirty nichts bewirkt, wieso habe ich dann alle Kachel im Browser auf einmal im aktellen Stand, so wie es sein soll?

Ich habe die Seite nicht mit F5 neugeladen.

Weil du gar nicht mit dem Renderingserver kommunizierst sondern mit dem Tilecache vorne dran (d.h. es funktioniert hin-und-wieder für eine spezifische Kachel, je nach Einstellung), da die Kacheln aber so oder so on-demand neugerenderet werden falls sie nicht aktuell sind, siehst du dann irgendwann natürlich den aktuellen Stand egal on du /dirty verwendet hast oder nicht.

@SimonPoole

Und ich habe wieder was gelernt. Schönen Dank für diese Erklärung.

Nichts hat sich geändert bis heute. Rein gar nichts …! Es wird mitunter sogar schlimmer den je!

Man muss sich mittlerweile schämen hier mitzumachen… !

Übrigens wird die Verkehrskarte auch nicht mehr aktualisiert - das Problem gab es in der Vergangenheit schon einmal, als die Verkehrskarte mehrere Monate lang stehenblieb. Eine Zeitlang hat es funktioniert, seit dem Update ist es wieder kaputt.

siehe https://forum.openstreetmap.org/viewtopic.php?id=66513

Kann ich nicht bestätigen. https://www.openstreetmap.org/way/773591641/#map=20/50.84942/6.22349&layers=T habe ich am 17.02.2020 eingetragen und wird auf der Verkehrskarte angezeigt, d.h. innerhalb der letzten 1 1/2 Wochen wurde die Karte aktualisiert. Das Update der Hauptkarte war Anfang Februar.

Muss dazu mal anmerken, dass ich (als einer der wenigen?) nicht davon betroffen bin.
Graue Kacheln habe ich wenig und wenn, dann nur 1-2 Sekunden lang.

Ansässig in Süddeutschland.
Kabelanbindung von Vodafone.
Mit Windows 10, Android oder Linux.
Chrome, Firefox Browser.
Josm oder ID Benutzer.

Meistens sind die Kachel schnell gerendert und werden angezeigt.
Das Problem kann ich aber folgendermaßen aber noch immer reproduzieren:
Ich zoome in eine Gegend immer weiter hinein (bis Zoomlevel 19) . Die Kachel kommen relativ schnell.
Nun verschiebe ich die Karte (geht noch gut), zoome dann wieder hinaus (Zoomlevel 17 funktioniert ganz gut) und verschiebe dabei weiter die Karte.
Dann kommt der Zeitpunkt, wo das (Neu-) Rendern zu deutlich und lang sichtbaren Kacheln führt. Dabei kommt es auch vor, dass einzelne Kacheln nicht mehr aktualisiert werden (Timeout des Frontend ?).

Dieses Vorgehen funktioniert sowohl in “leeren” Gegenden, die ich zuerst getestet habe (da dürfte die Wahrscheinlichkeit, dass Kachel bereits gerendert sind, sehr gering sein) und auch “stärker” besiedelten Gegenden.
Ich habe es auch noch in DE geschafft, graue Kachel zu produzieren (ebenfals in Zoom-Level 17).

Kann es sein, dass der Renderer unterschiedliche Prios für die Zoom-Level hat?

Ich glaub, das war´s irgendwie! Seit gestern ist OSM quasi tot. Bis auf die Stufe 1km/3000ft ist alles grau. Seit Stunden ! kein rendering …

Ich denke, ich bin raus einstweilen! Schade!

Peer

Wo?
Bei mir (Oberschwaben - Baden-Württemberg - D) ist alles i.O.

Am Albraa hab ich auch das Problem, dass etliche Kacheln in unzerschiedlichen Zoomstufen nicht neu gerendert werden, was eine gewisse Sichtkontrolle der Änderungen erschwert.

Wenn man die letzten paar Beiträge liest, bekommt man den Eindruck, dass das Problem sehr unterschiedlich ausgeprägt ist und stark von irgendwelchen Variablen abhängt. Bekommt man denn z.B. in Oberschwaben die Daten von einem anderen Tileserver als in Norddeutschland? Und/oder hängt das auch vom ISP ab?

Bei mir (nördliches Baden-Württemberg) ist das Problem irgendwo zwischendrin – Tiles kommen, aber langsam, und beim Reinzoomen wird es immer langsamer. Also weder „das war’s“ noch „alles i.O.“ Verschwunden ist das Problem jedenfalls noch nicht.

Es kann tatsächlich auch daran liegen, auf welchen Cache und welchen dahinterstehenden Renderer man zugreift.

Gerade bei denen, bei denen nur graue Kacheln erscheinen, könnte es daher auch hilfreich sein, wenn Ihr die Angaben unter Server Stats von diesem Link postet: https://tile.openstreetmap.org/cgi-bin/debug

Bei mir ist es übrigens seit ca. einer Woche wieder viel besser geworden, gelegentlich gibt es noch “Verstopfungen”, aber seltener.

Zudem muss unterschieden werden zw. dem Kachelladen auf openstreetmap.org und in eventueller anderer Anwendung/Webseite ← bei letzteren greifen sehr viel schneller Drosselungen und ggf. Blockaden.

Hier im Süden von Baden-Württemberg gibt es im Moment in ganz Deutschland auf www.openstreetmap.org keine Probleme mehr.

Zum Vergleich:

Und ich hatte eben, kaum dass ich obiges geschrieben hatte, mit katie als cache und odin als renderer wieder alles grau :slight_smile:

Unabhängig ob’s einen selber grade betrifft oder nicht, an der Sachlage hat sich nichts geändert:

  • 3 Renderserver sind dauerhaft überlastet - sieht man daran daß in den Statistiken Tiles gedroppt werden und in den “Gebirgskurven” die Spitzen fehlen und oben abschnitten sind.
  • solange Renderserver das Rendern abbrechen, werden immer wieder graue Tiles erzeugt - evtl. wird das durch Cacheprobleme noch verstärkt aber Caches unterliegen grundsätzlich dem SISO Prinzip (Sht in - Sht out)
  • Alle Renderserver sind durch die sukzessive Einführung von ST_PointOnSurface() im Kartenstil gegenüber dem Stand im Sommer deutlich langsamer geworden. Die großen Server haben Wochen statt Tage gebraucht, um sich vom Kartenstilupdate zu erholen, die 3 kleineren sind dauerhaft überlastet.

Daraus ergeben sich zwei Möglichkeiten, aus der dynsfunktionalen Rendersituation wieder rauszukommen:

  • entweder ST_PointOnSurface() komplett aus dem Kartenstil entfernen. Das sollte die Performance wie im Sommer sofort wiederherstellen
  • alle Renderserver auf Postgresql 10 Updaten, so daß ST_PointOnSurface() performant ausgeführt wird (solltem an aber vorher mal nachmessen, ob es tatsächlich genauso schnell wird wie vorher mit Mapnik)

Trotz der öffentlich erlebbaren und blamablen Situation: Passiert ist leider bisher gar nichts. :frowning:

Das Argument dagegen, dass ST_PointOnSurface() dafür verantwortlich ist, war ja, dass die Durchsatzleistung Metatiles/Sekunde bzw. der anteilige CPU-Verbrauch nicht gestigen sind:

https://github.com/openstreetmap/chef/issues/264#issuecomment-582729704

Deswegen wurde auch nichts unternommen.

Vom Admin gab es leider nur die sehr knappe Antwort, dass die Nachfrage das Angebot übersteigt, die Cache-Software Mist ist und der Dienst unter der Last kollabiert:

https://github.com/openstreetmap/operations/issues/366#issuecomment-589602213

Der kurzfristige Vergleich hinkt, nachdem das ST_PointOnSurface() über mehrere Updates reingekommen ist.

Wenn ich die Leistung von Odin im Normalbetrieb zwischen dem letzten Sommer und jetzt vergleiche:

am 23.7.2019:
7 Metatiles peak bei 900% CPU Last
=> 1.2 cpu/MT

am 28.2.2020:
16 Metatiles peak bei 4100% CPU Last
=> 2.5 cpu/MT

D.h. die Leistung von Odin hat sich gegenüber dem Sommer nahezu halbiert. Außer dem imperformanten ST_PointOnSurface() wurden bisher in den Diskussionen keine Gründe für diese Verschlechterung genannt.

Ich finde eine Leistungsverschlechterung von 1.2 auf 2.5 cpu/MT sollte eigentlich die Alarmglocken schrillen lassen. :frowning:

Wie kann das eine normale Ablauf sein? Wieso wird angefangen einen Tile zu renderen und wird das abgebrochen und damit der alte Tile gelöscht?
Das ist doch eine unsinnige vorgehensweise?

ja irgendwie komische herangehensweise, aber es wird schon irgendwelche Gründe haben… :roll_eyes:

Ich würde ja das alte Tile ja erst löschen, wenn das neue fertig ist… bis dahin das alte ausliefern… nach der Devise lieber ein altes als überhaupt keines :wink: Und diese aufwendige “ST_PointOnSurface()” Funktion… wird auch anscheinend ständig neu gerechnet anstatt das Ergebnis zu Cachen :confused:

gruß miche