Renderer pausiert/ ist verschnupft?

Da scheint irgend etwas nicht wie üblich zu funktionieren.
Ich habe gestern einige Gebäude eingetragen, welche auch nach kurzer Zeit in mehreren Zoomstufen sichtbar waren.
Jetzt sind die Gebäude in allen Zoomstufen wieder weg, in der Datenbank sind sie aber unverändert.

Gruß,
Mondschein

Auch das manuelle Anstoßen des Renderers mit Bildurl/dirty, das ich immer benutze, um meine Eintragungen auch in den kleineren Zoom-Stufen schneller zu sehen, funktioniert nicht mehr und erzeugt nur eine Fehlermeldung.

Der Renderer war nach http://munin.openstreetmap.org/openstre … index.html wohl gut zwei Stunden down, läuft jetzt aber wieder. Man sollte ihn für den Rest des Abends wohl besser in Ruhe lassen, auch ohne die downtime läuft er von Mittags bis Mitternacht unserer Zeitzone derzeit am Anschlag.

Grüße,

Baßtölpel

also eine kleine Erkältung... bei dem Wetter kein Wunder 😉

Danke...

Sven

Die Tiles von osm.org kommen bei mir zur Zeit auch nur stockend rein.

Ist irgendetwas angekündigt? Er rendert seit 4 Stunden nur z9-z12 🤔

Jimmy_K wrote:

Ist irgendetwas angekündigt? Er rendert seit 4 Stunden nur z9-z12 🤔

Nicht geplanter Hardwareausfall.

Gruß,
Mondschein

Jimmy_K wrote:

Ist irgendetwas angekündigt? Er rendert seit 4 Stunden nur z9-z12 🤔

Ist das nicht z17-z18, dieses dunklere lila? z9-z12 ist doch eher das blau, das man direkt nach der Pause kurz sieht, über grün.

Edit: Der Platform Status sagt "(rendering issues due to hardware failure)".

-

Jimmy_K wrote:

Ist irgendetwas angekündigt? Er rendert seit 4 Stunden nur z9-z12 🤔

Eben das, was die Leute mit /dirty pushen.

Baßtölpel

jetzt ist er wohl ganz ausgefallen 😐

Bekomme seit 2 Stunden nur noch Kacheln aus dem Cache angezeigt, alle anderen bleiben grau und werden nicht mehr geladen 🙁

och die kriegen das schon wieder hin...

ist sich Sven sicher.

/tiles füllt sich langsam aber sicher wieder: http://munin.openstreetmap.org/openstre … ap/df.html 😉

Wenn die graue Linie im ersten Bild wieder bei 88% angekommen ist, schätze ich mal ist alles wieder ok ^^.

Mondschein wrote:

Ich habe gestern einige Gebäude eingetragen, welche auch nach kurzer Zeit in mehreren Zoomstufen sichtbar waren.
Jetzt sind die Gebäude in allen Zoomstufen wieder weg, in der Datenbank sind sie aber unverändert.

Dito, aber jetzt weiss ich bescheid.
Nur ein verschnupfter Drache, alles klar. 🙂

Ich finde, dass das dreckige Rendern pro User nur 5 mal am Tag erlaubt werden sollte...

Nahmd,

Timmo wrote:

Ich finde, dass das dreckige Rendern pro User nur 5 mal am Tag erlaubt werden sollte...

Warum so restriktiv?

Ich bin für unbegrenztes Anfordern.

Für alle.
Für jeden.
Für 1¢/Kachel.

Gruß Wolf

Hier flutscht es wieder.
Neubaugebiet welches ich gestern vor ort erfasst habe (ja, es gibt noch eine Welt außerhalb von BING 🙂 ):
http://www.openstreetmap.org/?lat=51.77 … 7&layers=M

Netzwolf wrote:

Nahmd,

Timmo wrote:

Ich finde, dass das dreckige Rendern pro User nur 5 mal am Tag erlaubt werden sollte...

Warum so restriktiv?

Ich bin für unbegrenztes Anfordern.

Für alle.
Für jeden.
Für 1¢/Kachel.

Gruß Wolf

Wenn mir jetzt vielleicht noch ein Fachmann erklären kann, was so schlimm daran ist das Rendern mit /dirty anzustoßen?
Ich mache es auch manchmal. Aber ich lasse mich gern belehren und würde es unterlassen, wenn ich damit einen Schaden anrichte.
Den Tipp findet man ja schließlich auch im WIKI.

If you want to make a tile render before the seven day expiry then you can mark it as dirty by appending /dirty to the URL: http://tile.openstreetmap.org/7/63/42.png/dirty

Gruß
Peter

bei mir wirds auch besser, die Änderungen der letzten 3 Tage sind nun online 🙂

Und ich weiss jetzt auch, was bei meinen OpenLayers-Versuchen falsch war *gg*

Hallo,

mir sieht das so aus, als ob das, was vorher aus /dev/sdd gelesen wurde (die Tiles) jetzt aus /dev/sdc kommt und deshalb alle Tiles neu berechnet werden müssen.

Nach dieser grauen Kurve wird es noch etwas dauern, bis alle Tiles wieder neu berechnet sind.

War das vielleicht nötig, weil die /tiles-Partition fast voll war und man nun vielleicht mehr Plattenspeicher dafür reserviert hat?

Gruße,
Franz

FvGordon wrote:

Hallo,

mir sieht das so aus, als ob das, was vorher aus /dev/sdd gelesen wurde...

Nöö, dem ist nicht so: Ubuntu macht es Munin ein wenig schwer. Die Auswertungen der Platten erfolgt bei munin über den Device-namen (/dev/sd a b c ...). Diesen vergibt Ubuntu aber bei jedem Kaltstart neu sodaß ein und dieselbe Platte mal als sda oder auch mal als sdb usw auftaucht. Die normalen Munin-Scripte packen das leider nicht.
Hab das selbe Problem auf meiner Kiste und finde nie die Zeit, das mal endlich anzupassen - Sch... OSM 😉

Gruss
walter

chris66 wrote:

Hier flutscht es wieder.
Neubaugebiet welches ich gestern vor ort erfasst habe (ja, es gibt noch eine Welt außerhalb von BING 🙂 ):
http://www.openstreetmap.org/?lat=51.77 … 7&layers=M

Soso, und wo sind die Häuser? ;-)
Häuser ohne Luftbilder eintragen ist lästig---
aber dennoch: weiter so! GPS Tracks sind trotz BING nötig!

Amiga4000

wambacher wrote:

Nöö, dem ist nicht so: Ubuntu macht es Munin ein wenig schwer. Die Auswertungen der Platten erfolgt bei munin über den Device-namen (/dev/sd a b c ...). Diesen vergibt Ubuntu aber bei jedem Kaltstart neu sodaß ein und dieselbe Platte mal als sda oder auch mal als sdb usw auftaucht. Die normalen Munin-Scripte packen das leider nicht.

Darum benutze ich für solche Sachen unter Ubuntu die Symlinks unter /dev/disk/by-uuid/* - bisher hat das zumindest noch nie Probleme gegeben 😉

chris66 wrote:

Hier flutscht es wieder.
Neubaugebiet welches ich gestern vor ort erfasst habe (ja, es gibt noch eine Welt außerhalb von BING 🙂 ):
http://www.openstreetmap.org/?lat=51.77 … 7&layers=M

Melkenweg neben Rosen- und Tulpenweg hört sich komisch an...

Stimmt, der Name wurde aber bereits 2008 vom nicht mehr aktiven Mapper "Rapp" eingetragen.
Werde einen OSB Bug dort platzieren.

Die kommerzielle Konkurrenz ist aber auch der Meinung, dass es Melkenweg und nicht Nelkenweg ist. 😛

Verwirrung am Melkenweg

Petja wrote:

Wenn mir jetzt vielleicht noch ein Fachmann erklären kann, was so schlimm daran ist das Rendern mit /dirty anzustoßen?

Aus Erfahrung mit High Traffic Servern: Den Cache einen User verwerfen zu lassen ist ne ganz dumme Idee auf einem stark ausgelasteten Server. Irgend wann kommt der Zeitpunkt, an dem durch einen dummen Zufall das zu viele gleichzeitig tun.

Stelle Dir vor: Du verwirfst Kachel XYZ. Der Server ist aber stark ausgelastet. Jemand anderes fordert diese Kachel in der Webseite an - aber der Rebuild ist noch nicht fertig. Der Server merkt "hoppla, Kachel XYZ muss ja neu erstellt werden" - und der Renderprozess dieser Kachel startet sogleich nochmal. Der Server kommt so nimmer hoch, es bildet sich eine endlose Warteschleife an Jobs. Und in der Regel wissen die einzelnen Userrequests tatsächlich nichts voneinander (und will man solche Fälle erkennen, so kostet das enorme Resourcen - und wieder ist die Performance weg). Dazu kommt noch: Webserver weisen jedem Request eine bestimmte Menge Speicher zu. Trifft nun aber das Szenario zu, dass zu viele Request in der Summe mehr Speicher verbrauchen als vorhanden ist, gibts Probleme (faktisch eine DOS Attacke).

Ein ordentliche programmierter Cache verteilt sein Last automatisch über den Tag, das pendelt sich ein. Ein User nicht.

Ich habe mir nicht angesehen, wie die Infrastruktur bei OSM aufgestellt ist oder mod_tiles des Apache programmiert ist. Würde aber ganz sicher ein manuell gewünschtes Rendern niemals auf der Hauptmaschine durchführen, sondern auslagern und danach auf den Liveserver kopieren.

Timmo wrote:

Ich finde, dass das dreckige Rendern pro User nur 5 mal am Tag erlaubt werden sollte...

Gibt es dafür auch eine gute Begründung?

"/dirty" und das Ansehen von veralteten Kacheln unterscheiden sich nicht wirklich sehr.
Wenn du ein Gebiet mit veralteten Kacheln ansiehst, dann werden da üblicherweise sehr viel mehr (>5) Kacheln neu erstellt (falls die Warteschlange nicht voll ist), sogar mehr, als du zu sehen bekommst (Prefetching).

Gruß,
Mondschein

Joachim Moskalewski wrote:

Der Server merkt "hoppla, Kachel XYZ muss ja neu erstellt werden" - und der Renderprozess dieser Kachel startet sogleich nochmal. Der Server kommt so nimmer hoch, es bildet sich eine endlose Warteschleife an Jobs.

Die Warteschlange ist auf 1k Kacheln beschränkt, ist diese voll, dann werden alle weiteren Anfragen verworfen, bis wieder Platz in der Warteschlange ist.
Hierbei ist es egal, ob diese Anfragen durch "/dirty" oder durch die Anforderung von veralteten Kacheln ausgelöst werden.

Übrigens sieht man hier sehr schön, dass die Warteschlange sehr selten voll ist, es sei denn, es fallen z.B. Festplatten aus, die Datenbank wird neu importiert oder es laufen mal wieder massenhaft irgendwelche Tile-Downloader:
http://munin.openstreetmap.org/openstre … queue.html

Gruß,
Mondschein

Mondschein wrote:

Die Warteschlange ist auf 1k Kacheln beschränkt, ist diese voll, dann werden alle weiteren Anfragen verworfen, bis wieder Platz in der Warteschlange ist. [...] http://munin.openstreetmap.org/openstre … queue.html

Danke für diese Information. Aus meiner Beobachtung der letzten Tage schließe ich nun, dass 1000 ein zu hoher Wert ist. Und das "Anfrage verwerfen ab 1k Warteschlange" habe ich als "Kachel kommt halt bei keinem User mehr an" kennengelernt - also auch nicht die abgelaufene Kachel. Dein Link zeigt zudem, dass "dirty" tatsächlich ein Problem ist - denn genau dies sorgte für das Vollaufen der Warteschlange, und somit auch für leere Kartenausgaben bei mir bzw. www.openstreetmap.org.

Eine Grenze der Warteschlange halte ich für richtig, aber der Mechanismus des Löschens veralteter Kacheln müsste m.E. überdacht werden: Da würde ich den Besuchern von www.openstreetmap.org lieber eine Kachel von gestern statt gar keiner präsentieren. Eventuell nach einem definierten Schema umbenennen statt löschen, und via mod_rewrite eine Fallbackregel für nicht vorhandenen Tilegrafiken auf die verschobenen bzw. veralteten setzen.

Warum die veralteten Kacheln überhaupt löschen? Reicht es nicht aus, wenn eine Kachel aktualisiert wird, die alte Datei mit der neuen zu überschreiben? Ich nehme mal an, dass es sowieso in ner Datenbank erfaßt ist, wann welche Kachel erstellt wurde bzw. ob sie neu erstellt werden muss...

reneman wrote:

Warum die veralteten Kacheln überhaupt löschen? Reicht es nicht aus, wenn eine Kachel aktualisiert wird, die alte Datei mit der neuen zu überschreiben? Ich nehme mal an, dass es sowieso in ner Datenbank erfaßt ist, wann welche Kachel erstellt wurde bzw. ob sie neu erstellt werden muss...

Der Server erhält die Anfrage nach Grafik XYZ - und merkt, diese muss neu erstellt werden. Der Webbrowser wartet, bis der Server diese ausliefert - oder bricht bei zu langem Warten mit einem Timeout ab. Und das passiert so lange, bis die Grafik "erneuert" wurde. D.h. es ist egal ob gelöscht oder nicht, ob überschrieben oder nicht - die alte Garfik wird schlicht nicht ausgeliefert, da sie neu zu rechnen ist.

Soll heißen: Ob gelöscht oder überschrieben wird ist eigentlich egal (da habe ich zuvor unsauber formuliert), die Frage ist: Wie kann man es bewerkstelligen, eine veraltete Grafik dennoch auszuliefern? Dazu bedarf es ein Indiz "Renderprozess wurde angestoßen", um während dieser Zeit die alte Grafik auszuliefern. Das könnte man - wie von Dir angedacht - mit einer Datenbank machen. Ich würde aus Erfahrung hier aber eher zu Dateioperationen raten. Es ist auch üblich bei einem Webcache diesen nicht via Datenbank zu überwachen, sondern z.B. den Modified Zeitstempel der Cachedatei heranzuziehen - eben weil so ein Cache (was auch die aktuellen Tiles letztlich sind) i.d.R. versucht, Datenbanktraffic zu verhindern. Und jeden Aufruf einer Grafik durch ein Script mit Datenbankconnect zu schleußen ... da würde ich beim Tileserver massive Probleme erwarten.

Daher mein Gedanke: Renderprozess verschiebt zuerst, weshalb eine Fallbackregel via htaccess greift - und der Tileserver läuft für alle weiteren Benutzer sauber und schnell weiter, auch während ein Tile neu gerendert wird. Ist das neue Tile fertig, geht es nahtlos weiter. Statt jeden Request während des Rebuilds aufwändig zu bearbeiten. Lücke wäre hierbei noch, dass langfristig vermutlich einzelne Kacheln gänzlich verloren gehen könnten (fehlgeschlagene / abgebrochene Rebuilds würden für permanentes Ausliefern aus dem Fallback-Cache führen). Das ließe sich aber via cronjob herausfinden.

Anyway, ich schreib hier große Reden - umsetzen kann ich das aktuell ohnehin nicht... Ist somit reine Theorie.

Joachim Moskalewski wrote:

Aus meiner Beobachtung der letzten Tage schließe ich nun, dass 1000 ein zu hoher Wert ist.

Nein.

Joachim Moskalewski wrote:

Und das "Anfrage verwerfen ab 1k Warteschlange" habe ich als "Kachel kommt halt bei keinem User mehr an" kennengelernt - also auch nicht die abgelaufene Kachel. Dein Link zeigt zudem, dass "dirty" tatsächlich ein Problem ist - denn genau dies sorgte für das Vollaufen der Warteschlange, und somit auch für leere Kartenausgaben bei mir bzw. www.openstreetmap.org.

"dirty" ist kein Problem.
Wenn die Warteschlange voll ist, dann liefern die Tile caching Server veraltete Kacheln aus, falls im Cache vorhanden, wenn aber Teile des Caches auf Grund eines Hardwaredefekts nicht verfügbar sind, dann müssen diese Kacheln neu erzeugt werden, was auf dem Tile-Server zu einer kurzfristig stark erhöhten Auslastung führt.
Durch den aktuellen Ausfall sieht man deutlich, was passiert, wenn man plötzlich nicht mehr so viel Zwischenspeicher hat.

Joachim Moskalewski wrote:

Eine Grenze der Warteschlange halte ich für richtig, aber der Mechanismus des Löschens veralteter Kacheln müsste m.E. überdacht werden: Da würde ich den Besuchern von www.openstreetmap.org lieber eine Kachel von gestern statt gar keiner präsentieren.

Wird gemacht, wenn es keinen Hardwareausfall gibt.

Joachim Moskalewski wrote:

Eventuell nach einem definierten Schema umbenennen statt löschen, und via mod_rewrite eine Fallbackregel für nicht vorhandenen Tilegrafiken auf die verschobenen bzw. veralteten setzen.

OSM hat 6 Tile caching Server (2x England und je 1x Schweden, Russland, Australien und Frankreich).
Diese speichern einige TB Kacheln zwischen.

Hier kann man übrigens sehen, wie sich die Kacheln auf die Zoomstufen verteilen:
http://wiki.openstreetmap.org/wiki/Tile_Disk_Usage

Gruß,
Mondschein

@Joachim Moskalewski:
Es ist doch grundsätzlich so, dass ich als Kartenbetrachter eine Kachel sehen will. Ob es die aller neuste ist ist i.d.r. zweitrangig. Da ich schon häufiger beobachten konnte, dass die Auslieferung der Kacheln "ein wenig länger" gedauert hat wäre es in meinen Augen eine wesentliche Verbesserung wenn eine wie von dir vorgeschlagene Verbesserung umgesetzt werden könnte. 🙂

reneman wrote:

Warum die veralteten Kacheln überhaupt löschen? Reicht es nicht aus, wenn eine Kachel aktualisiert wird, die alte Datei mit der neuen zu überschreiben?

Wird so gemacht, sollte der Zwischenspeicher aber voll sein, werden alte Kacheln gelöscht, um neuen Kacheln Platz zu machen.

reneman wrote:

Ich nehme mal an, dass es sowieso in ner Datenbank erfaßt ist, wann welche Kachel erstellt wurde bzw. ob sie neu erstellt werden muss...

Ja.

Gruß,
Mondschein

Joachim Moskalewski wrote:

Der Server erhält die Anfrage nach Grafik XYZ - und merkt, diese muss neu erstellt werden. Der Webbrowser wartet, bis der Server diese ausliefert - oder bricht bei zu langem Warten mit einem Timeout ab. Und das passiert so lange, bis die Grafik "erneuert" wurde. D.h. es ist egal ob gelöscht oder nicht, ob überschrieben oder nicht - die alte Garfik wird schlicht nicht ausgeliefert, da sie neu zu rechnen ist.

Nein, wenn der Tile-Server zu lange für die Erstellung der Kachel benötigt oder die Warteschlange voll ist, dann wird eine veraltete Kachel (falls vorhanden) aus dem Tile-Cache ausgeliefert.

Joachim Moskalewski wrote:

Wie kann man es bewerkstelligen, eine veraltete Grafik dennoch auszuliefern?

Wird gemacht.

Joachim Moskalewski wrote:

Dazu bedarf es ein Indiz "Renderprozess wurde angestoßen", um während dieser Zeit die alte Grafik auszuliefern.

Wenn eine Kachel angefragt wird, welche nicht aktuell ist, dann versucht der Tile-Server diese sofort zu erstellen, dauert das zu lange, kommt es zu einem Timeout und der Tile caching Server liefert eine alte Kachel aus (falls vorhanden).

Joachim Moskalewski wrote:

Das könnte man - wie von Dir angedacht - mit einer Datenbank machen. Ich würde aus Erfahrung hier aber eher zu Dateioperationen raten.

Wenn ich mich richtig erinnere, dann wird das bei OSM so gemacht.

Gruß,
Mondschein

reneman wrote:

Es ist doch grundsätzlich so, dass ich als Kartenbetrachter eine Kachel sehen will. Ob es die aller neuste ist ist i.d.r. zweitrangig. Da ich schon häufiger beobachten konnte, dass die Auslieferung der Kacheln "ein wenig länger" gedauert hat wäre es in meinen Augen eine wesentliche Verbesserung wenn eine wie von dir vorgeschlagene Verbesserung umgesetzt werden könnte. 🙂

Genau deswegen gibt es doch bei OSM die Tile caching Server.