Graue Kacheln in OpenStreetMap.com

Ü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

Nach meinem Verständnis wird weder mitten im Rendering abgebrochen, noch wird nichts (graues Tile) geliefert wenn es stattdessen noch ein altes Tile auf dem angefragten Server gibt.

Anfragen nach noch nicht vorhandenen Kacheln werden in eine Warteschlange mit der höchsten Priorität (“Priority request Queue”) eingereiht, siehe Renderd throughput Statistik (Summe aller). Erst wenn kein Platz mehr in der begrenzten Warteschlange ist, wird die Anfrage ohne sofortiges Ergebnis mit HTTP code 404 (nicht gefunden) beantwortet, siehe auch mod_tile HTTP response codes Statisik (einzelne Server), und das Rendering für später in die “Dirty Queue” aufgeschoben, wenn die anderen Warteschlangen abgearbeitet sind. Für mehr Details dazu habe ich diesen Kommentar gefunden.

Ich hatte letzte Woche zu unterschiedlichen Zeiten getestet und am Freitag einen weiteren Kommentar zum Issue geschrieben.

Nach meiner Beobachtung sind graue (fehlende) Kacheln Antworten mit HTTP Code 404 (nicht gefunden), allerdings nicht von den üblichen Cache Servern in Deutschland (kalessin, katie, keizer, konqi) und dem Render Server odin, der Deutschland zugeordnet ist, sondern von anderen Caches/Servern.

Da gibt es wohl eine Verteilung der einzelnen Anfragen von einem Cache auf einen scheinbar beliebigen und zufälligen anderen, die bei hoher Last auftritt, besonders tagsüber an Werktagen und speziell nachmittags. Und wenn auf schwächere Server verteilt wird, die zudem auch die Tiles noch gar nicht haben, weil sie primär für andere Regionen zuständig sind, dann bekommt man gehäuft graue Kacheln.

Besser als mit der Debug-Seite kann man das in den Entwickler-Tools (F12) im Tab “Network”/“Netzwerkanalyse” beobachten. In den Details zu einer Kachelanfrage (Klick auf Zeile), gibt es unter “Response Headers”/“Antwortkopfzeilen” die Header “x-cache” mit dem Cache Server und “x-tilerender” mit dem Render Server. In Chrome kann man diese Custom Header per Rechtsklick auf die Kopfzeile auch direkt zur Anfrage-Tabelle hinzufügen (siehe Referenz).

Mittlerweile kann man ja kaum noch OSM empfehlen ohne auf die grauen Kacheln hinzuweisen (zeitweiliges Problem). Heute nachmittag war es besonders schlimm. Jetzt geht es einigermaßen beim zoomen.

In den letzten Tagen ging es bei mir, jetzt ist es wieder furchtbar. QMapShack wartet seit drei Minuten auf 41 Kacheln, das Bild ist rein gelb (keine Kachel geladen).

Zum Glück gibts OsmAnd Live, da kann man seine Änderungen auch bald sehen :slight_smile:

–ks

https://twitter.com/OSM_Tech/status/1239561292572241921