In der ersten Juni-Hälfte hat die Overpass API nicht so zuverlässig wie gewohnt gearbeitet. Mittlerweile konnte die Overpass API wieder zum Normalbetrieb zurückkehren. Wenn ich selbst anderswo solche Ausfälle erlebe, möchte ich eine Erklärung haben. Daher im Folgenden ein paar Details zu der Ausfallzeit:

Was ist passiert?

Am letzten Dienstag, 6. Juni, ist die Anzahl der Anfragen von ca. 50.000 – 80.000 pro Tag auf fast 1.000.000 pro Tag angestiegen. Erfreulicherweise hat sich auch die Anzahl unterscheidbarer IP-Adressen von 300 pro Tag auf etwa 6000 erhöht. Allerdings ist der Server mit dieser drastisch angestiegenen Last überfordert – ein Slashdot-Effekt. Fast alle Abfragen wurden mit einer HTML-Seite, dass der Server überlastet ist, beantwortet.

Die neu auflaufenden Abfragen sind alle von der Form xapi?*[amenity=*][bbox=...]. Erfreulicherweise wird eine Kennung des User Agents mitgeschickt, so dass ich die Abfragen der iOS-App „Geomon“ zuordnen kann. Es sieht so aus, als wenn die Timeout-Meldungen keinerlei Effekt auf das Verhalten der App haben.

Unabhängig davon fällt am Freitag aus ungeklärten Gründen die Rambler-Instanz aus: die erste Unregelmäßigkeit ist, dass ein Durchlauf des Compilerwerkzeugs make mit einer nicht reproduzierbaren Fehlermeldung abstürzt. Danach gibt es Konsistenzehler bei der Area-Erzeugung, ebenfalls nicht reproduzierbar. Einige Stunden später gelingt es mir nicht mehr, mich per ssh einzuloggen, und der Webserver zeigt nicht einmal mehr die statische Website. Im Gesamtbild spricht fast alles für einen Hardware-Schaden. Im Nachhinein stellt es sich als ein Problem mit dem Rambler-internen NFS heraus; mein Home-Verzeichnis liegt nicht physisch auf dem gleichen Server wie der Overpass-Server, so dass dieser mein Home-Verzeichnis nicht mehr lesen konnte. Ich frage einen Reboot an, aber der Server bleibt unerreichbar.

Um die Performance für die meisten Anwendungen zu erhalten, auch wenn die Benutzerzahl von Geomon die aller anderen Anwendungen dominiert, habe ich daher zu diesem Zeitpunkt spezifisch die XAPI-Anfragen auf maximal 3 parallele Anfragen gedrosselt, so dass Overpass-QL-basierte Anwendungen weiterhin etwa die gewohnte Leistung erreichen.

Parallel dazu beginne ich für overpass-api.de einen Umzug vom vier Jahre alten Hetzner DS5600 (4 GB RAM, AMD K5600+) auf einen aktuellen Hetzner EX6S (32 GB RAM, Xeon E3-1245). Auf dem neuen Server habe ich diese Grenze auf 10 parallele Anfragen anheben können, so dass jetzt auch 90%-95% der Anfragen im XAPI-Format wieder ausgeführt werden.

Am 14. Juni ist dann das NFS-Problem auf dem Rambler-Server wieder behoben – der zuständige Administrator war nicht im Büro, und die Nachrichten-Weiterleitung hat nicht wie erwartet funktioniert. Jetzt funktioniert auf overpass.osm.rambler.ru wieder alles normal.

Ist overpass-api.de generell überlastet?

Generell muss sich niemand, der weniger als 10.000 Anfragen pro Tag erzeugt, darüber Gedanken machen. Die Leistungsgrenze des alten Servers liegt bei etwa 100.000 Anfragen pro Tag, die des neuen etwa bei 1.000.000 Anfragen pro Tag. Bei Lasttests haben sich auf dem neuen Server bis zu 10.000 Abfragen pro Minute als handhabbar herausgestellt, je nach Größe der Anfragen.

Knapp sind auf dem Server vor allem Festplattenzugriffe, im Englischen, der Server ist „I/O bound“. Die eigentlich gute Performance von Overpass API beruht darauf, Geodaten in Blöcken von 512KB statt einzeln zu lesen. Eine typische Anfrage wird das Lesen von 3-4 Blöcken auslösen, und der Server kann etwa 10 pro Sekunde lesen. Die beobachtete Geschwindigkeit liegt aber deutlich darüber, was dafür spricht, dass sehr viele Blöcke erfreulicherweise statt von der Festplatte aus dem RAM-Cache gelesen werden. Sehen kann man dies am Munin-Diagramm: es werden sogar mehr Daten geschrieben als gelesen.

Nicht knapp ist dagegen die CPU-Zeit. Das Munin-Diagramm zeigt uns, dass die Prozessoren ganz erheblich Zeit für die Area-Aktualisierung verwenden können und zu noch mehr Anteilen unbeschäftigt sind, was der gezeigte, orange bzw. gelbe Nice-Anteil ist.

Die eigentliche Schwierigkeit liegt jedoch darin, dass Anfragen schubweise kommen, zum Teil bis zu 5000 pro Minute. Für statische Webseiten wäre dies nicht viel, für Datenbankabfragen ist es allerdings sehr viel. Während solcher Schübe ist es unter Umständen nicht möglich, alle Abfragen zu bearbeiten, während dies im Normalbetrieb gewährleistet ist.

In der Vergangenheit hat es auch andere problematische Nutzungsmuster gegeben: allen voran ein offenbar auf Seiten des Client abgebrochener Download größerer Teile des Planeten, der vom Server weiterverfolgt, aber vom Client mehrfach erneut versucht worden ist.

Welche Maßnahmen bestehen?

Generell ist Overpass QL von vorneherein für die Ressourcen-Steuerung ausgelegt. Dazu wird für jede Abfrage zunächst der RAM-Bedarf und die Laufzeit geschätzt. Dies kann entweder explizit der Nutzer mit den entsprechenden Direktiven tun, oder der Server nimmt Default-Werte von 180 Sekunden und 512MB RAM an.

Überschreitet eine Anfrage den RAM-Bedarf oder ihre geschätzte Laufzeit, wird sie abgebrochen. Dies stellt sicher, dass große Abfragen von den Nutzern auch als große Anfragen gekennzeichnet werden. Umgekehrt entscheidet der Interpreter vor der Ausführung der Anfrage, ob noch genug Ressourcen für die Ausführung zur Verfügung stehen. Dies stellt sicher, dass zumindest nicht einzelne große Anfragen den Server blockieren können.

Overpass QL ist zudem defensiv entworfen: eine aufwendige Abfrage hat auch einen langen und umständlichen Quelltext, so dass nur sehr selten versehentlich große Anfragen gestellt werden.

Warum ist speziell XAPI problematisch?

Im Gegensatz zu Overpass QL ist XAPI dafür konzipiert, Resourcen-Grenzen vor dem Benutzer zu verbergen. Das führt dann dazu, dass ausgerechnet die einfachsten Abfragen wie „xapi?*[highway]“ viel zu große Ergebnisse sowohl für den Server als auch für den Client liefern.

Tatsächlich ist dieser Konflikt zwischen Konzept und Realität die Haupt-Antriebsfeder gewesen, anstelle von XAPI eine imperative Skriptsprache zu konzipieren.

Welche Maßnahmen bestehen nicht und warum?

Keine Filterung besteht nach IP, User Agent oder ähnlichem.

Scraping von einer einzelnen IP-Adresse in solchem Umfang, dass es den Server blockiert, habe ich noch nicht beobachtet. Auf der anderen Seite gibt es Implementierungen, die für die Overpass-API-Daten als Proxy agieren. Dann sehe ich von vielen Nutzer-IP-Adressen nur eine Proxy-IP-Adresse, was dann fälschlicherweise nach einem Scraper aussieht.

Ein ähnliches Problem stellt sich bei den User Agents: Fast alle Browser, einschließlich einiger Internet-Explorer-Versionen, beginnen den User-Agent mit „Mozilla“. Browser-Mash-Ups sind aber erwünschte Nutzer. Es ist sogar noch schlimmer: würden einzelne Browser als User-Agents blockiert, sieht ein Website-Entwickler nicht reproduzierbare Unterschiede zwischen verschiedenen Browsern oder Versionen, für die man üblicherweise in den Browsern und nicht bei einem Datenlieferanten nach den Ursachen suchen würde.

Wie geht es weiter?

Auch in Zukunft wird der Server auf hohe Last einer populär werdenden Anwendung nur mit Überlast-Meldungen reagieren können. Es gibt nach dem Umzug durchaus erhebliche Reserven für den Normalbetrieb, aber mehr als eine Zehnerpotenz Lastreserve lässt sich nicht sinnvoll vorhalten.

Anders ausgedrückt: bei einem öffentlichen, kostenlosen Server sollte niemand erwarten, dass der Server jederzeit problemlos funktioniert, eben weil andere Nutzer den Service überlasten könnten. Wer Zuverlässigkeit garantieren möchte, sollte eine eigene Instanz betreiben – dafür ist die Software Open Source und leicht zu installieren.

Für mich selbst habe ich den Anspruch, Störungen in weniger als 24 Stunden zu beheben, so dass auch weiterhin Projekte ohne Geld für einen Server trotzdem Zugriff auf ein leistungsfähiges Backend für OSM-Daten bekommen können.

In diesem Sinne möchte ich mit der guten Meldung schließen, dass dank dem Lastproblem die Software durch neue Optimierungen jetzt zum Teil erheblich schneller antworten kann. Das „Geomon“-Team ist mittlerweile auf einen eigenen Server umgezogen, so dass nun größere Server-Power mit effizienterer Software für die gleichen Nutzerzahlen auf Overpass API zur Verfügung steht.