in den letzten Tagen ist OSM etwas schwerfaellig. Das liegt an verschiedenem (u.a. Problemen mit Postgres 8.4), aber vor allem liegt es daran, dass es staendig Leute gibt, die mit 10-20 parallelen Prozessen Daten von OSM absaugen (also den /map-Aufruf der API benutzen, der von Editoren zum Datendownload “alles in diesem Rechteck” verwendet wird).
Dieser Aufruf ist nur fuer Editoren oder ab und zu mal einen Download gedacht, aber nicht dafuer, dass man Hunderte von kleinen Rechtecken herunterlaedt, um Daten fuer eine grosse Flaeche zu bekommen. (Der Aufruf hat ja ein Groessenlimit, maximal sind 0.5*0.5 Grad erlaubt.)
Ich schreibe das hier, weil die groessten “Suender” fast immer von t-dialin.net-Adressen kommen, also aller Wahrscheinlichkeit nach aus Deutschland. Keine Ahnung, ob hier irgendein toller Vektor-Renderer verbreitet ist oder irgendeine Software, die auf diese Weise massiv Daten herunterlaedt, oder ob es ein paar einzelne Leute mit Downloadskripts sind oder so. Aber: Diese Leute ignorieren die Nutzungsbestimmungen fuer die OSM-API, und wegen dieser Leute ist es fuer alle Mapper langsamer als sonst.
Wenn ihr also mal irgendwo auf einem Stammtisch oder im Forum jemanden prahlen hoert nach Art von “ich brauch die XAPI nicht und auch keine vorgefertigten Extrakte, ich lade mir einfach mit meinem XYZ-Skript die ganzen Daten immer von der API runter…”, dann packt mal gleich die verbale Keule aus und teilt demjenigen freundlich, aber bestimmt mit, dass dieses Verhalten auf Kosten aller geht.
(An technischen Massnahmen wird auch gearbeitet, aber manchmal hilft ja ein direktes Wort besser…)
Paar Volt sind noch im Akku, also noch schnell:
Für Rechtecke im Bundeslandkaliber, wo fertige Extrakte aber nicht ganz passen, wäre die XAPI zuständig?
Das klingt eher nach schlechter Programmierung oder schlechtem Index (oder full-table-Scans). MySQL liefert im Vergleich zu Postgres auch nahezu doppelte Leistung, trotzdem wird OSM schon einen Grund zum Wechseln gehabt haben.
Wenn aber schon bei SELECT Querys die Server schlapp machen …
Die API schafft übrigens 0.25er Bereiche, nicht 0.5.
Tja, wenn es darum geht, wuerde ich vor allem gleich auch mal schauen, wie man MOBAC (Mobile Atlas Creator) sperren kann. Damit screenshoppen Leute Mapnik auf Z16 mal eben fuer ganze Bundeslaender oder sogar Deutschland.
Nein, bitte bloss nicht MOBAC sperren. Auch ich nutze ab und zu MOBAC - zwar nicht für ganze Bundesländer geschweige von Länder… Aber MOBAC ist sehr gut geeignet, um Tiles für osmtracker-android herunterzuladen, damit man dann unterwegs nicht übers Mobile die Tiles ziehen muss (vorallem wenn man im Ausland ist, wird es sonst teuer).
Das gleiche habe ich damals auch für osmtracker für WM6.1 gemacht - einfach mit JTileDownloader… Somit müsste man ja JTilesDownloader auch sperren… Bitte aber nicht…
Eigentlich sollte das ja klar sein, dass man nicht gleich ganze Länder in Zoom=16 herunterläd… Aber ich weiss, es gibt natürlich Leute, die es trotzdem machen. Und wenn es zu viel Traffic wäre, könnte man ja eine Bremse einbauen: z.b. nach einem Download von vielleicht 2500 Tiles eine Zwangspause von 10 Minuten… Serverseitig sollte das realisierbar sein (vielleicht nicht aufgrund der Anzahl Tiles, aber über die Downloadgrösse)… Und so würden sich die Leute dann schon eher Gedanken machen, ob sie wirklich jedesmal ein ganzes Land herunterladen wollen…
Ich könnte mir vorstellen das dort auch ein paar Apps (z.B. für Android) dahinter stecken die OSM nutzen. Die Funktion gibt es z.B. in Oruxmaps was zunehmend populärer wird. ( siehe z.B. http://www.androidpit.de/de/android/market/apps/app/com.orux.oruxmaps/OruxMaps > 50000-250000 downloads) Also man kann von seinem aktuellen Standort ein Gebiet von x km * x km downloaden so das die Daten offline (auf dem android) zur Verfügung stehen. Im Online modus werden die tiles nur nach Bedarf (download der betrachteten tiles) heruntergeladen und wenn schon vorh. kommen sie aus dem cache, es werden also weniger Daten nachgeladen als wenn man z.B. im www nur die mapnik Karte schaut. ein Problem dabei ist aber das man dann mit alten tiles unterwegs ist. ich vermute da wird sich noch etwas tun in dem Bereich.
Das offline zur Verfügung stellen ist nebenbei bemerkt DAS Feature überhaupt an oruxmaps.
Ob die App zu den Problemen beiträgt kann ich dir nicht sagen, das müssest du mal klären.
0,5° entsprechen wie viel kilometer ? (55 ?) Ich hatte mal versucht ein Gebiet von 20x20km zu laden, da kam es aber nach einer gewissen Zeit zu einem Abbruch. Ein Limit scheint es in dem sinne bei Oruxmaps nicht zu geben. Es würde mich aber nicht wundern wenn andere da evtl noch größere Gebiete versuchen runterzuladen. Evtl. kannst du dich ja mal mit jose vazquez kurzschließen. Er ist recht ‘kommunikativ’ und offen für Verbesserungsvorschläge.
Nebenbei bemerkt eignet sich die App auch recht passabel zum mappen. (Davon abgesehen das es die geilste “outdoor GPS App” überhaupt ist )
Ja gut aber dann müssen die Mirrors erstellen, das kostet heute ja auch nichts mehr und für die ist das ja auch besser weil sie dann einheitlichere Daten haben und die zentral postprocessen können.
Gibt es im Wiki eigentlich irgendwo einen Überblick, was die einzelnen Server machen und wie sie über die diversen Protokolle miteinander verknüpft sind?
Schon klar, aber Mobac ist soweit ich das sehen kann auch ein fettes Problem - und zwar wird dadurch das komplette On Demand Rendering einfach unmoeglich. Das User Rasterkarten en Masse runterladen - ist einfach nicht fuer OSM geeignet. Als Vektorkarte waere das Downloadvolumen wahrscheinlich nicht mal ein Zehntel. Zurzeit haben sicherlich Portale wie Outdooractive mit Mobac groeßere Probleme (sprich ganz Deutschland als Top25 liegt IMHO bei rund 40GB, dazu 20GB als Top50, 10GB fuer Top100, etc…) aber sicherlich wird Mobac noch fuer fette Probs sorgen.
Gibt in den tiefen des Netzes genug Anleitungen wie man mit MOBAC ganze Laender als Top25 Topokarten von diversen Portalen ziehen kann.
Es ist zu viel traffic und es wurde deshalb (teilweise) eine Bremse eingebaut. Nach N mb wird auf X kb/s gedrosselt. (kenne die Werte nicht da sie teilweise wechseln). Allerdings verusrsacht teilweise die dafeur noetige “Buchhaltung” auch zusaetzlichen load, kann also nicht sonderlich clever sein. Insgesammt wird damit auch noch experimentiert, um zu versuchen so wenig wie moeglich “legitime” Nutzer zu beeinflussen aber moeglichst viele Scraper damit “einfaengt”.
Das betrifft aber alles nicht die map call der API, dort sind keine Bremsen eingebaut. Teilweise, weil die Limits wesentlich niedriger und dynamischer sein muessten, als viel schwieriger korrekt einzustellen. Waerend die Tile server um die 1000 - 2000 Requests pro Sekunde verarbeiten koennen, sind es bei der Api eher 10 - 20, bei groesseren gegenden auch deutlich weniger. Wenn also jemand jetzt mit 10 threads gleichzeitig map calls abfraegt, kann ein einzelner die komplette API ueberlasten.
Im uebrigen ist XAPI auch haeufig ueberlastet, da da das gleiche Problem ist nur das XAPI auch noch auf schwaecherer Hardware laeuft (nur stoert es da nicht so sehr, da sich dort zum Teil “nur” die scraper gegenseitig ausbremsen). Mit groesseren Ausschnitten, (bzw. allen Ausschnitten die nicht direkt zum mappen gedacht sind) muss man einfach die planet extracts verweden. Das ist das einzige fuer das so einigermassen ausreichend Kapazitaet zur verfuegung steht mit den derzeitigen Resourcen.
Den code findet man unter http://git.openstreetmap.org/. Wenn man einzelne Verbesserungen vorschlagen kann die die Sache nachweislich schneller machen waeren die Admins mehr als dankbar. Hinweise der Form nimm einfach mal das Program dann wird alles schon besser hilft hingegen wenig.
Full table scans passieren in dem code aber ziehmlich sicher nicht. Da wuerde ein einzelner scan dann schon mal 10 minuten dauern und nicht ein paar Sekunden. Das ist am Anfang (bei der Umstellung auf CGI-Map) passiert und das war ganz schnell zu sehen und wurde desshalb sofort wieder reverted, bis es gefixed wurde.
Gibt es Zahlen zu dieser Behauptung? Bassierend auf was, welche Datenmenge, welche Hardware, welches Schema?
Jede Hardware, jedes Schema. Zahlebn: Google, Datenmenge: Egal. Ab gewisser Zeit machen aber Oracle mehr Sinn, wobei MeinSQL ja auch von Oracle gekauft wurde - das lässt für die Zukunft hoffen.
Weiterhin: Erfahrung. Aber danke für den Source, den schau ich mir auf jeden Fall mal an.
Hat nicht MySQL Probleme mit dem Index auf Geodaten?
Ich hab gerade eine Harddisk gekauft und werd die OSM Daten in eine DB spielen.
Bisher war ich der Meinung, dass MySQL nicht wirklich geeignet ist.
Ist aber schon ziemich ausgereizt von Leuten, die sich ziemlich gut auskennen. Denke schon, dass man noch das eine oder andere besser machen kann, aber wenn irgendjemand irgendwo full table scans machen wuerde, waere das Ding schon vor zwei Jahren an die Wand gefahren
Der Map-Call ist nun mal komplex (und die Schreibrequests fordern dem Server weniger ab, insofern ist “schon bei SELECT” nicht angebracht). Du musst erst alle passenden Nodes in der Bounding Box raussuchen. Dann alle Ways, die diese Nodes benutzen. Dann alle Nodes, die von den herausgesuchten Ways benutzt werden (koennten ja Ways ueber die bbox rausstehen). Dann dasselbe fuer Relationen. Und jedesmal so queries mit "… where node_id in (n1, n2, n3, n4, … n31845). Da wird halt einfach viel rumgeroedelt.
Man koennte mal ueberlegen, einen read-only-MySQL-Mirror mit MyISAM-Tabellen einzusetzen, die sind naemlich wirklich schnell. Fuer die zentrale Datenbank mit Schreibrequests brauchen wir Transaktionen, und MySQLs InnoDB-Tabellen haben weder die geforderte Performance noch die notwendigen Features.
Ja. Sagte ich doch. 0.5*0.5 Grad = 0.25 Quadratgrad.
Der Geodatensupport bei MySQL ist unterdurchschnittlich (viele Standardfeatures sind nur rudimentaer implementiert, aber dafuer gehts auch schneller). Fuer einen OSM-Datenbankserver ist das aber irrelevant, weil der gar keine GIS-Extensions braucht (benutzt auch reine Postgres, nicht PostGIS).
In einem Single-User/SIngle-Task-Umfeld, wo man nicht befuerchten muss, dass mehrere Leute gleichzeitig konkurrierende Edits machen und man sich Transaktionen deswegen sparen kann, kann man grundsaetzlich unbesorgt MySQL einsetzen. Allerdings ist bei OSM mittlerweile Postgres der Standard, so dass es manchmal vorkommt, dass Leute irgendwas neu entwickeln, was nur auf Postgres geht, und dann muss es erst wieder irgendjemand auf MySQL portieren.
Stimmt. Es gibt 3 API-Frontend-Server und jeder hat maximal 20 Map-Prozesse, d.h. es braucht drei User mit je 20 Threads, aber selbst das geben unsere freundlichen t-dialin-User ab und zu her
Es wird darueber nachgedacht, den map-Request wieder - wie es frueher schonmal war - nur fuer registrierte Benuzter anzubieten. Das wuerde das Problem entweder schnell loesen, oder man wuesste wenigstens, wer die Leute sind und koennte sie anschreiben.
ja bitte!!! da hätte ich effektiv nichts dagegen…
soben 48 kleine Änderungen (davon 32 Knoten) per JOSM hochgeladen: über 5 Minuten zum hochladen… uffff… jepp… API ist aktuell extrem langsam… (und schon der Download dieses Bereichs dauerte mehrere Minuten)
)