Kurz vor Weihnachten hat die Overpass API einige Anfragen deutlich langsamer als gewohnt beantwortet. Das ist zwar recht bald wieder besser geworden. Aber seitdem verhält sich die Overpass API an einer anderen Stelle weniger schnell als gewohnt: Ist normalerweise der Datenstand nur 1-2 Minuten hinter der Hauptdatenbank, so ist er im Moment in den Abendstunden oft bis zu 30 Minuten hinter dem Datenstand der Hauptdatenbank.
Dies kann man am Wert „Lag to OSM Main Database“ hier ablesen.
Das erste Phänomen hängt allein mit Areas zusammen: Entgegen meinen Vermutungen auf Talk-De lag es nicht direkt an einer Fläche über den Südpol, sehr wohl aber an der neu erfassten Fläche für die Antarktis. Diese Fläche soll alles südlich des 60 Grades südlicher Breite umfassen. Das ist mal locker ein Sechstel der Koordinatenfläche in Längen-Breitengrad-Systematik und damit z. B. ein Vielfaches der bereits riesigen Fläche von Russland. Das war zu groß für die Software. Das Problem ist bis auf Weiteres dadurch gelöst, dass die Erzeugung sehr großer Flächen jetzt übersprungen werden. Es betrifft die Gesamtrelationen für Russland, Australien und eben mehrere Antarktis-Relationen. Damit kann dann auch ein wohlmeinender Mensch mit einer Eurasien- oder Pazifik-Relation nicht mehr die Datenbank sprengen.
Aber woher kommt der Rückstand zur Hauptdatenbank und wann wird das wieder besser? Zeit für Detektivarbeit!
Fangen wir mit dem Naheliegenden an: Gibt es mehr Andrang auf der Overpass API? Danach sieht es nicht aus. Die Anzahl unterschiedlicher IP-Adressen pro Tag ist seit September bei 4000 etwa gleich geblieben. Die Anzahl der Queries ist sogar gefallen, aber da Queries unterschiedlich groß sein können, muss das nichts heißen. Es kommt durchaus vor, dass Nutzer über 10.000 Objekte einzeln per Id abfragen – das macht kaum Last, erhöht aber stark den Query-Zähler.
Die übertragene Datenmenge ist andererseits gestiegen, aber erstens bei weitem nicht so stark, dass dies die Last erklären könnte, und vor allem passt die Verteilung kaum zu den Lastspitzen des Update-Prozesses.
Unser Detektiv würde sich also wohl eher anderen Verdächtigen zuwenden, aber die Leser mögen das Phänomen im Hinterkopf behalten.
Der nächste Verdächtige ist die Datenbank für die nächste Version der Overpass API. Diese wird zwei maßgebliche Verbesserungen bringen. Zum einen wird die auf der SoTM 2013 (korrigiertes Video) angesprochene Kombination aus großer Bounding-Box und Tag-Kriterium schneller, denn die Datei, die Tags auf Ids abbildet, merkt sich jetzt auch geographische Indizes. Zum anderen wird die Datenbank die volle Historie seit dem Lizenzwechsel bekommen, so dass man beispielsweise auch abfragen könnte, welche Briefkästen in Bonn im Dezember 2012 gemappt gewesen sind.
Das erfordert allerdings, mit einem Planet vom Lizenzwechsel zu starten und alle Diffs seitdem auf die Datenbank anzuwenden. Das durchzurechnen dauert etwa einen Monat und passiert seit dem 21. Dezember.
Eigentlich kann es die aktuelle Version nicht beeinträchtigen, da die neue Version mit ionice läuft. Ionice ist ein Werkzeug des Linux-Kernels, um die Festplatten-Priorität für einzelne Prozesse zu verändern. Die neue Datenbank wird mit so niedriger Priorität gerechnet, dass nur dann Zugriffe stattfinden sollten, wenn für die aktuelle Version nichts zu tun ist. Auf die gleiche Weise ist übrigens generell auch die Area-Erzeugung herunterpriorisiert.
Beides funktioniert sehr wirksam: Sowohl die Area-Erzeugung als auch die neue Datenbank werden weniger als halb so schnell bearbeitet, wenn die aktuelle Version mehr als eine Minute Verspätung sammelt. Anders ausgedrückt: die beiden Verdächtigen haben ein sehr gutes Alibi.
Zeit für einen ungewöhnlicheren Verdächtigen: die aktuelle Version bietet die sogenannten Augmented Diffs – Diffs, die alle Geometrie-Information explizit enthalten, damit man diese auch einzeln ohne Datenbank auswerten und darstellen kann. Die Diffs werden z. B. für Norbert Renners Achavi genutzt (laufende Instanz).
Die Erzeugung ist zwangsläufig mit den normalen Updates verzahnt, denn dabei stehen die benötigten Daten zur Geometrie ja genau zur Verfügung. Allerdings kann das trotzdem viel Zeit brauchen: Wenn nämlich ein Knoten einer großen Relation, z. B. der deutschen Grenze angefasst wird, ändert sich deren Geometrie. Und für den vollständigen Augmented Diff müssen dann die geometrischen Daten der ganzen deutschen Grenze gesammelt werden. Das kostet Zeit.
Tatsächlich spielt das eine Rolle, denn die Datenmengen pro Stunde Datenbank-Zeit (und nicht die Größe eines einzelnen Diffs, diese ist für einen mehrminütigen Diff sowieso größer als für einen einminütigen) sind in den Abendstunden tatsächlich spürbar größer. Allerdings gilt auch hier: Größen-Rekorde hat es im Dezember nicht gegeben, sondern in den Monaten vorher, in denen die Overpass API auch abends näher am Puls der Zeit war. Wir haben also einen Teil des Rätsels geklärt, nämlich warum speziell von 17 bis 24 Uhr sich die Verzögerungen häufen.
Übrigens wird dieses Problem mit der neuen Version besser: dann können Augmented Diffs bei Nachfrage erzeugt werden, was nicht nur beliebige Zeiträume (1 Sekunde ebenso wie mehrere Monate) erlauben wird, sondern eben das Problem, die Geometrie vollständig nachschlagen zu müssen, vom Update-Prozess entkoppelt.
Unauffällig dazugekommen ist auch eine andere Funktion: Die auf dem Export-Tab von osm.org seit neuestem erwähnte Map-Export-Funktion (mit der eigenwilligen Übersetzung „API überführen“ – hört sich an, als wenn da eine Maschine übersetzt hat. Kann man eigentlich Übersetzungen weniger aufwendig als mit einem Pull-Request beitragen?). Diese könnte eine hohe Last erklären, weil sie es leicht macht, große Datenmengen abzufragen. Andererseits verhindert ein eher aggressiver unumgänglicher 5-Minuten-Timeout, dass die Abfragen zu aufwendig werden.
Um die Last des Map-Aufrufs gesondert herauszufinden, habe ich das Logging erweitert: Laufzeiten abzufragen wäre kontraproduktiv, weil gleich aufwendige Abfragen ja langsamer laufen, wenn generell die Server-Last höher ist. Man findet dann nur neu heraus, was man schon vorher wusste. Die schlichte Anzahl der Abfragen hilft hier nicht, weil ja gerade der Verdacht besteht, dass spezielle Abfragen viel aufwendiger als die Durchschnittsabfrage sind.
Also zähle ich jetzt Plattenzugriffe. Da fast alle Plattenzugriffe der Overpass API einheitlich je 512K en bloc lesen, reicht zählen hier aus. Das hat eine große Überraschung gebracht.
Zu erwarten wären grundsätzlich etwa 8 Zugriffe pro Sekunde bzw. knapp 30.000 Plattenzugriffe pro Stunde, da die Festplatte ihren Lesekopf jeweils zum Anfang des Blocks bewegen muss. Die Messungen ergeben aber mehr als 1.2 Mio. Zugriffe pro Stunde (20.000 pro Minute), also das 40-fache! Dann spielt der Cache eine viel größere Rolle, als ich bisher immer vermutet habe. Der Cache ersetzt Festplattenzugriffe durch Abrufe vorhandener Kopien der gleichen Daten im RAM, was etwa um den Faktor 1000 schneller geht als ein Festplattenzugriff. Demnach kommen also wohl knapp 98% aller Blöcke statt von der Festplatte vom Cache. Das spricht sehr für die Qualität der Cache-Algorithmen im Linux-Kernel.
Entgegen der Erwartungen passt aber das Lastmuster bei den Plattenzugriffen nur äußerst schlecht zu den Lastspitzen der Update-Funktion. Das allein erklärt es also nicht.
Es hat mich aber auf eine andere Hypothese gebracht, und wie es sich für einen guten Krimi gehört, ist sie durchaus etwas verworren: Die Leistungsfähigkeit der Update-Funktion hängt maßgeblich davon ab, wie groß der Anteil der Datenbank ist, der im Cache statt nur auf der Festplatte liegt. Wenn nun die zweite Datenbank bearbeitet wird, belegt diese ebenfalls einen erheblichen Teil des Caches. Dazu kommt, dass die Map-Abfragen gerne viel RAM belegen. Das spielt alles eine untergeordnete Rolle, solange nicht für die Augmented Diffs große Datenmengen gewälzt werden müssen. Aber so machen sich die Augmented Diffs jetzt bemerkbar, während vorher der Cache die zusätzliche Last kaschiert hat.
Wenn die Erklärung richtig ist, wird sich die Lage entspannen, wenn die neue Version aktiv wird. Diese braucht ja weniger Last für die Augmented Diffs. So sehe ich also gespannt dem Moment voraussichtlich Ende Januar entgegen, wenn die Datenbank für neue Version auf die aktuelle Zeit aufgeholt hat.
Wie viele Tiles sind das? [1]
Jérôme Gagnon-Voyer visualisiert mit OSM (leider fehlt der Hinweis) 
Letzte Änderung an Straßen 
Die Reit- und Wanderkarte übersetzt … 
Mit Hoursome auf iOS nach geöffneten POIs suchen …