Nachbau des Mapnik-Stils mit CartoCSS für OSM.org

Ich habe gerade getestet und nicht ungewöhnliches festgestellt.

Die fehlende Statistik kann ich bestätigen.

sonst weiß ich aber auch nichts.

Die “fehlende” Statistik liegt daran das der Server gewaechselt wurde. Die Kacheln werden nun von Orm gerender und ausgeliefert. Dem entsprechend finden sich die Statistiken nun unter http://munin.openstreetmap.org/openstreetmap/orm.openstreetmap/index.html . Yevaud wird gerade neu installiert und ebenfalls auf Carto umgestellt. Nach dem neu Import wird er dann als zweiter tile Server wieder zur Verfuegung stehen. Im Moment ist so weit ich weis geplant diese unabhaengig von einander zu Betreiben und manche Laender ueber den einen Server und andere Laender ueber den anderen Server laufen zu lassen.

Bezueglich /diry: das sollte im Prinzip schon funktionieren. Da nach dem Stylechange wie oben erwaehnt der komplette Cache “invalidiert” wird und somit alles neu gerendert werden muss, ist der Server damit derzeit etwas ueberlastet und verwirft somit viele /dirty Anfragen ( http://munin.openstreetmap.org/openstreetmap/orm.openstreetmap/renderd_processed.html die dropped Statistik ) Das gilt auch fuer das renderen von sich geaenderten Tiles, wodurch die automatische Aktualisierung der Tiles nicht so gut wie normalerweise funktioniert. Das duerfte sich in ca 1 - 2 Tagen wieder legen wenn der Server ausreichend Kacheln neu gerendert hat um mit der Menge an Anfragen wieder klar zu kommen.

Da das bei jedem Style-Update wieder geschehen wird, ueberlege ich mir gerade in mod_tile / renderd eine weitere Prioritaetsstuffe einzubauen um die Aktualitaet waerend der cache invalidation Phase nicht (oder weniger) zu gefaehrden.

Was ich mich schon lange frage: warum ist die Queue auf eine derart geringe Länge (1000) beschränkt? Wenn nicht gerade massenhaft Niedrigzoomkacheln gerendert werden müssen, trägt Mapnik diese Queue in zwei Minuten ab. Bei höherem Limit (zunächst etwa 10^5; bei positiven Ergebnissen auch mehr) würden weniger Anfragen (dirty) verworfen und stattdessen einfach später ausgeführt.

Der noch gueltige Hauptgrund duerfte sein das es als etwas “verkappte” Prioritisierung fungiert. Wenn der Renderer ueberlastet ist und X% der Anfragen verwirft hat jede Anfrage eine gewisse Wahrscheinlichkeit das just in dem Moment ein Platz in der Queue frei ist und diese somit dann gerendert wird. Sehr beliebte Kacheln senden viele Anfragen an den Renderer und sehen somit eine deutlich erhoehte Wahrscheinlichkeit das wenigstens eine der Anfragen in die Queue rein kommt. Damit werden die viel besuchten Tiles prioritisiert.

Historisch hat es noch einen Performance Grund. Bei jeder Anfrage muss die Queue durchsucht werden um Duplikate zu finden. Da die Queue urspruenglich als linear list umgesetzt war, war die Queue Laenge stark begrenzt. Das ist aber schon seit langem nicht mehr der Fall. Das Limit wurde aber nie angepasst.

Abgesehen davon ist es fraglich wie weit eine verlaengert Queue tatsaechlich etwas bringt. Zumindestens in Faellen wie jetzt, wo die Queue ueber Tage hinweg am Anschlag ist (inklusive waerend der Nacht) gibt es kein wirklich naehe liegendes “Spaeter” auf das man es verschieben kann. Mit der gestiegenen Performance (Orm schaft inzwischen ca 14 metatiles / s) wird die Queue zeitlich gesehen jedoch immer kuerzer. Die 1000 metatile queue ist inzwischen gerade einmal knapp ueber einer Minute. Insofern ist denke ich eine gewisse Erhoehung durch aus sinnvoll und moeglich.

Für Situationen, wo der ganze Cache verworfen werden muss (insbesondere bei Änderungen des Styles), sollte man sich eventuell eine andere Strategie überlegen, wie von dir bereits angedeutet.

@Oli-Wan:
Ich würde die Cache-Größe nicht gleich um den Faktor 10 erhöhen. Eine Verdoppelung auf 2000 könnte man jedoch durchaus mal ausprobieren. Je nach dem, wie sich das in den verschiedenen Situationen (Normalbetrieb / Cache verworfen) auswirkt, kann man dann weiter erhöhen oder ggfs. auch wieder einen niedrigeren Wert einstellen.

Eine Queue-Größe von 2000 würde bei 14 Meta-Tiles/sek einen Backlog von knapp über 2 Minuten noch ohne Ausfälle bewältigen. Wenn man jedoch wie zur Zeit ca. 200 Metatiles pro Sekunde verwerfen muss, dann hilft eine Queue-Größe von 10000 wahrscheinlich auch nicht mehr viel.
Wenn in Zukunft das Verwerfen des Cache öfter notwendig wird, dann hilft wahrscheinlich nur eine Anpassung der Strategie. Dabei stellt sich natürlich die Frage, was wichtiger ist: angefragte Kacheln oder geänderte Kacheln.

Edbert (EvanE)

@amm: Danke für die Erläuterungen, damit wird einiges klarer.

Die behelfsmäßige Priorisierung würde mit einer längeren Queue genauso funktionieren, sobald diese gesättigt ist, nur daß die “erfolgreichen” Requests länger bis zur Ausführung warten müßten. Bis die Queue voll ist, werden zumindest alle noch eingestellt statt verworfen, und gewöhnliche Lastspitzen (also alles außer einer Style-Änderung) könnten besser abgefangen werden. Wobei ich mich frage, ob bei einer Style-Änderung überhaupt alles neu gerendert werden muß - dafür, daß bloß hier und da ein paar Objekte neu auftauchen oder sich einzelne Symbole ändern. Meist sind es ja Änderungen im Detail, die sich in den niedrigen Zoomstufen kaum auswirken. Es wird ja wohl nicht von heute auf morgen das Meer lila werden.

@EvanE: Ich habe nicht einen Faktor 10 vorgeschlagen, sondern einen Faktor 100. Das ist immer noch ein Aufkommen, das im Normalfall in zwei oder drei Stunden abgearbeitet ist. Einen Faktor 2 würde man vermutlich kaum sehen.

Prima, dass man das auch mal erfährt :frowning: Im Wiki steht immer noch Yevaud als Renderer drin und da schaut man dann natürlich nach, wenn es mal klemmt.

Gruss
walter

Sorry, da habe ich falsch gerechnet / unaufmerksam gelesen.
In dem Fall ersetze Faktor 2 durch Faktor 10. Das sollte für einen Test erst einmal genügen. Man weiß ja nie im voraus, ob nicht irgendwelchen unerwarteten Nebeneffekte auftreten.

Edbert (EvanE)

Auf welche Wiki Seite beziehst du dich? (Es gibt wahrscheinlich viele Seiten auf denen etwas falsches steht… ;)) Dann kann man sie vielleicht aendern.

Wobei die Information sich vermutlich in den naechsten Tagen schon wieder aendern werden. Yevaud ist halb durch mit dem re-import und wenn der fertig ist wird Yevaud dann schaetzungsweise auch wieder in den Dienst gestellt. Wie genau die Arbeitsteilung dann zwischen Orm und Yevaud aussehen wird weis ich nicht. Ich weis auch nicht ob das ueberhaupt schon entschieden ist. Wenn sich das System etwas mehr heraus kristalisiert hat, wird man schauen koennen ob man die Statistiken dafuer verbessern kann und die relevanten Information einfacher zugaenglich machen kann.

http://wiki.openstreetmap.org/wiki/Platform_Status
Direkt auf der Wiki-Hauptseite verlinkt.

Gruß,
Mondschein

Ah, der gute alte Platform Status. Den hatte ich ganz vergessen… Naja, ich habe den jetzt geaendert und werde versuchen dran zu denken den auch wieder weiter zu aendern wenn yevaud wieder ebenfalls verwendet wird.

Nicht ganz:
Platform_Status wurde inzwischen angepasst - ich meinte aber Servers - da hatte ich nachgesehen, weil ich dort den neuen Server suchte.

Danke für’s Anpassen und Schwamm drüber.
Walter

ps: wenn ich die lokale IP wüßte, könnte ich es sogar ändern; aber amm wird das schon hinkriegen. :wink:

Man hat generell zwei Optionen:

  • Lastverteilung: Ein Render-Server für Europa/Asien/Afrika,
    Ein Render-Server für Amerika, Ozeanien, Pazifik.
  • Ausfallsicherheit: Beide Render-Server erzeugen die gleichen Daten.

Das sollte man sorgfältig abwägen.
Mit verteilten Tile-Servern hat man ja bereits Erfahrungen, auf denen man ggfs. aufbauen kann.

Edbert (EvanE)

Ich würde Lastverteilung bevorzugen. Damit geht das Rendern neuer Seiten überall für alle schneller.
Ausfallsicherheit erscheint mir nicht ganz so wichtig, solange die vorgeschalteten Tile-Server überhaupt etwas ausliefern - und das tun sie ja.

Gruss
walter

…und im Ernstfall könnte man immer noch dem überlebenden Tile-Server sagen, er soll alle Cache-Server beliefern.

Im Moment ist wie gesagt geplant das einige der Frontend Caches auf den einen Rendering Server zugreifen und die anderen Frontend Caches auf den anderen Rendering Server.

Das heist wenn man z.B. in Deutschland sitzt bekommt man die Tiles von Server A gerendert, ob man nun einen Auschschnitt in Deutschland betrachtet oder einen in den USA oder Australien. Umgekehrt wenn man z.B. in den USA sitzt bekommt man alle seine Tiles von Server B gerendert. Insofern haben beide Server alle noetigen Daten und mehr oder weniger auch Tiles.

Da jedoch vermutlich Leute in Deutschland ueberwiegend Kartenausschnitte in Deutschland betrachten und die die in den USA sitzen ueberwiegend amerikanische Ausschnitte, und da die tiles on demand aktualisiert und neu gerendert werden, sollte das ganze auch eine deutlich Lastverteilung ergeben ohne das man die Ausfallsicherheit (uebermaessig) reduziert. Es kann beim “fail-over” dann jedoch fuer eine Zeit haeufiger zu veralteten Tiles kommen, da die Tiles in der anderen Region zwar weitestgehend vorhanden sein duerften, aber eben nicht so akutell gehalten werden und es dann zu einer Ueberlastung des on-the-fly updatens kommen kann.

etwas OT:

Dann könnte man ja leicht unterschiedliche Rendering-Rules implementieren: Die Amis sehen auf “ihrem” Renderer geblurte Military Areas und wir kriegen die volle Pracht :wink:

Duck&Cover
Walter

Ah ja gut.
So kann man eine Lastverteilung erreichen, ohne dass man die Ausfallsicherheit opfern muss.

Edbert (EvanE)

Nun sind sowohl Orm als auch Yevaud im Betrieb und rendern “froehlich” vor sich hin.

Inzwischen sind damit 12 Frontend Proxyserver verteilt in der Welt und 2 Rendering Backendserver in London im Betrieb um sicher zu stellen das die Standard OSM Kacheln so schnell, zuverlaessig und aktuell wie moeglich sind.

Die geographische Verteilung der Laender auf die einzelnen Proxies kann man unter http://dns.openstreetmap.org/tile.openstreetmap.org.html sehen und die Verteilung der Proxyserver auf die backend rendering server unter http://dns.openstreetmap.org/render.openstreetmap.org.html .

Dort sieht man das Deutschland derzeit von einem Proxyserver von Hetzner in Falkenstein versorgt wird, der wiederum seine Tiles von Yevaud bekommt.

Wobei sich die Konfiguration der Frontend und Backendserver jederzeit aendern koennen wenn sich das System selbst reconfiguriert um etwaige Ausfaelle oder Ueberlastungen auszugleichen.

WoW !

Die Sache sieht wirklich rund aus - wenn ich noch an OSM von 2009 denke (da bin ich eingestiegen) so liegen da Welten dazwischen.

Gratulation - und weiter so.

Gruss
walter