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
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
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
Darum benutze ich für solche Sachen unter Ubuntu die Symlinks unter /dev/disk/by-uuid/* - bisher hat das zumindest noch nie Probleme gegeben
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. 
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.
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
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/openstreetmap/yevaud.openstreetmap/renderd_queue.html
Gruß,
Mondschein
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…
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.
Nein.
“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.
Wird gemacht, wenn es keinen Hardwareausfall gibt.
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. 
Wird so gemacht, sollte der Zwischenspeicher aber voll sein, werden alte Kacheln gelöscht, um neuen Kacheln Platz zu machen.
Ja.
Gruß,
Mondschein
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.
Wird gemacht.
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).
Wenn ich mich richtig erinnere, dann wird das bei OSM so gemacht.
Gruß,
Mondschein
Genau deswegen gibt es doch bei OSM die Tile caching Server.