Graue Kacheln in OpenStreetMap.com

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

Jetzt haben wir auch eine entsprechende Einblendung (Bitte, Caching-Server bereitzustellen) beim Start von JOSM – danke an das Team!

Wie wär’s denn, wenn wir für die Zeit, in der das System “kaputt” ist, einfach z19 abstellen? Dann sollte nach meinem Verständnis sofort mindestens die doppelte Leistung da sein.

P.s. mir fällt seit ca. heute Mittag auf, dass es deutlich zügiger zu laufen scheint aktuell.

Das ist leider entfallen, da die Corona-geschädigte Konferenz kurzfristig abgebrochen wurde und somit der OSM-Tag nicht stattfand.

Auch eine von mir initiierte Meldung in der Wochennotiz mit Verweis auf diesen Thread hat offenbar niemand Befähigten zu einer Reaktion animieren können. Dabei hatte ich ursprünglich auf die Blamage abgestellt und formuliert: “Das deutschsprachige Forum diskutiert [hier] darüber, wie sich das OpenStreetMap Projekt seit mehreren Wochen mit einer nahezu unbenutzbaren Karte auf seiner Homepage openstreetmap.org blamiert.” Das wurde dann in der Wochennotiz 501 redaktionell weichgespült zu: “Mapper äußerten sich im deutschen OSM-Forum enttäuscht über die schlechte Rendererperformance der OSM-Hauptkarte.”

Zum eigentlichen Problem: Mal läuft es perfekt mit Reaktionszeiten beim Scrollen auch in der höchsten Zoomstufe unter einer Sekunde. Ein anderes Mal ist die Karte in nahezu jeder Zoomstufe vollkommen unbrauchbar. Die bisherigen Erklärungsversuche können so ein wechselhaftes Verhalten nicht wirklich begründen.

Mit so einer Karte kann man keine neuen Mapper werben. Im Gegenteil werden bisherige Mapper abspringen, die Ihre Edits nicht mehr vernünftig prüfen können. So werden hier Jahre mühsamer Werbearbeit in kürzester Zeit zunichte gemacht. :frowning:

Ich verstehe nicht, wieso man so eine Systemänderung, die die Server doch eindeutig und dauerhaft in die Knie zwingt, nicht sofort wieder rückgängig macht und dann erstmal in einer Sandbox testet.

Das geht seit fast zwei Monaten so!

–ks

Die offizielle (?) Begründung für die Probleme sind jetzt Ausfälle bei den Caching-Servern, nicht die Stiländerung (vgl. https://twitter.com/OSM_Tech/status/1239561292572241921 usw.). Keine Ahnung, was davon wie richtig ist, ich kann das nicht beurteilen, nur als Hinweis …

Dass das Problem immer noch besteht ist leider wahr – dass keiner reagiert nicht ganz. Es wurden zum einen diverse neue Cache-Server dazugeschaltet, zum anderen Nutzer identifiziert, die in großem Stil Last erzeugen (und damit begonnen, diese zu kontaktieren bzw. ihnen den Zugriff abzustellen). Nur eine Minderheit der Last stammt nämlich von osm.org oder anderen Seiten aus der OSM-Community.

Diese Maßnahmen basiert natürlich auf der Analyse der OWG, dass das Problem in der Überlastung der Cache-Server liegt, nicht bei den Render-Servern oder dem Kartenstil.

Momentan ist es bei mir wieder furchtbar. osm.org ist praktisch unbenutzbar. Ich geh schon zu Google, um mir Straßenverläufe anzusehen, weil ich keine Lust habe, nach jedem Kartenverschieben 20 Sekunden zu warten, bis die Hälfte der Kacheln da ist.

Das ist kein Zustand und macht null Spaß! In einem Freiwilligenprojekt ist das tödlich!

Ich stell mir gerade eine Wikipedia vor, wo es nach einer Bearbeitung erstmal eine halbe Stunde dauert, und dann ist erst jeder zweite Halbsatz im Artikel aktualisiert und der Rest sieht noch aus wie vorher …

Das Problem trat Anfang Februar plötzlich auf. Das muss doch einen Grund haben.

Und ich wäre wirklich froh, wenn mal jemand sagen könnte, woran genau das liegt und was man dagegen tun könnte. Wird einfach nur größeres Material gebraucht? Dann sagt es doch! Es wäre schön, wenn wir gemeinsam bald eine Lösung dafür fänden. Seit etwa acht Wochen blamieren wir uns netzweit mit dem Frontend derart, dass kein Detaillierungsgrad der Geodaten mehr dagegen ankommt.

–ks

Seh ich das richtig, dass es kürzlich ein carto-Update gegeben hat, mit wieder etwas kräftigerem Grün für ZL ≤ 12?

Nochmal zusätzliche Last auf den Render-Servern :slight_smile:

–ks

Ja, v5.0.0
https://github.com/gravitystorm/openstreetmap-carto/blob/master/CHANGELOG.md
Das kräftigere Grün kommt durch “Reduced landcover fading at mid-low zoom levels (#3952)”

Dann bin ich mal gespannt, ob sich diese Änderung positiv bemerkbar macht:

Allerdings verweist die OWG-Erklärung für die grauen Kacheln ja nicht auf dieses Render-Problem, sondern auf Probleme mit Cache-Server (und Nutzern, die große Last erzeugen). Kann also sein, dass sich nichts ändert …

Ja! Jetzt sind die Kacheln grün (Ausschnitt aus https://www.openstreetmap.org/#map=12/50.7192/10.5292):

Ciao

tracker51