OSM langsam - wegen Massendownloads

woodpeck wrote:

nach Art von "ich brauch die XAPI nicht und auch keine vorgefertigten Extrakte,

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?

Wohl eher der nächst größere extract. Also wenn du Ostthüringen und Westsachsen brauchst, dann halt germany.osm

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

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.

extremecarver wrote:

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/mar … s/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.

extremecarver wrote:

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.

Hi,
es ging hier um den API- und nicht den Tile-Server.

Und was Tiles angeht, die kann man auch von dem schnellen Strato Server laden (werden allerdings nur wöchentlich
aktualisiert)

Grüße, Chris

chris66 wrote:

es ging hier um den API- und nicht den Tile-Server.

Gibt es im Wiki eigentlich irgendwo einen Überblick, was die einzelnen Server machen und wie sie über die diversen Protokolle miteinander verknüpft sind?

Wyo

wyo wrote:

chris66 wrote:

es ging hier um den API- und nicht den Tile-Server.

Gibt es im Wiki eigentlich irgendwo einen Überblick, was die einzelnen Server machen und wie sie über die diversen Protokolle miteinander verknüpft sind?

Wyo

hier: http://wiki.openstreetmap.org/wiki/Servers
und hier ist der Status dazu.

chris66 wrote:

extremecarver wrote:

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.

Hi,
es ging hier um den API- und nicht den Tile-Server.

Und was Tiles angeht, die kann man auch von dem schnellen Strato Server laden (werden allerdings nur wöchentlich
aktualisiert)

Grüße, Chris

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.

efred wrote:

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...

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.

deltabrasil wrote:

Das klingt eher nach schlechter Programmierung oder schlechtem Index (oder full-table-Scans).

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.

deltabrasil wrote:

MySQL liefert im Vergleich zu Postgres auch nahezu doppelte Leistung, trotzdem wird OSM schon einen Grund zum Wechseln gehabt haben.

Gibt es Zahlen zu dieser Behauptung? Bassierend auf was, welche Datenmenge, welche Hardware, welches Schema?

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.

deltabrasil wrote:

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.

deltabrasil wrote:

Das klingt eher nach schlechter Programmierung oder schlechtem Index (oder full-table-Scans). ...
Wenn aber schon bei SELECT Querys die Server schlapp machen ....

Programmierung kannst Du Dir selbst angucken, der Map-Call wird von "cgimap" hier verarbeitet:

http://git.openstreetmap.org/?p=cgimap.git;a=summary

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.

deltabrasil wrote:

MySQL liefert im Vergleich zu Postgres auch nahezu doppelte Leistung, trotzdem wird OSM schon einen Grund zum Wechseln gehabt haben.

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.

deltabrasil wrote:

Die API schafft übrigens 0.25er Bereiche, nicht 0.5.

Ja. Sagte ich doch. 0.5*0.5 Grad = 0.25 Quadratgrad.

Bye
Frederik

robotnic wrote:

Hat nicht MySQL Probleme mit dem Index auf Geodaten?

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.

Bye
Frederik

amm wrote:

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.

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.

Bye
Frederik

woodpeck wrote:

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.

Bye
Frederik

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)

Potlatch scheint gar nicht mehr zu reagieren......ist das das Ende??

speedpilgrim > µMap

EDIT: Nein, hat nur 10min gedauert 🙂

woodpeck wrote:

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 😉

Jeder (naja, die meisten) map request braucht aber deutlich laenger als eine Sekunde, insofern, mit 60 processen bekommt man vermutlich trotzdem nur einen durchsatz von 10-20 requests pro Sekunde.

20 Threads auf den map call ist aber schon reichlich dreist. Mit der Menge wuerden sie ja selbst auf dem Tileserver moeglicherweise gebannt...

woodpeck wrote:

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.

Oh, hat sich Mat bereit erklaert OAuth in CGI-map zu implementieren? Dann koennte man vielleicht auch anschliessend den changeset upload nach CGI-map portieren. Das wuerde hoffentlich dann auch die CPU last auf den drei Servern reduzieren.

Neben dem Update auf Postgress 8.4, das moeglicherweise einzelne Performance Probleme verursacht, scheint auch ploetzlich seit dem Update die CPU Auslastung der Railsserver zum Problem gewordern zu sein ( http://munin.openstreetmap.org/openstre … p/cpu.html ). Ob das durch das Update von Hardy auf Lucid zustande gekommen ist? Oder doch eher, weil der DB-server schneller geworden ist und somit Rails mehr zu tun bekommen hat?

Eventuell macht es Sinn, die API Calls per IP einzuschränken, damit man sich nicht ganze Deutschlanddaten ziehen kann sondern nur - 10 Requests pro Stunde im Format 0.25 x 0.25. Oder entsprechend mehr, wenn man nur kleinere Bereiche lädt. Das löst doch das Problem :-)

Naja...ein reconnect mit dem Internet (=neue IP-Adresse) dauert keine 30sec und lässt sich prima automatisch ausführen.

Sinnvoll wäre das ganze zu verschlüsseln, sodass map-reuests nurnoch dazu verwendet werden, wozu sie gedacht sind.

Hallo aighes,

dann bricht das automatische Script aber ab, wenn eine Range spammt dann wird die Range gesperrt, ob Telekom Dir ne neue aus der Rage gibt ist eine gute Frage. Die Methode sperrt aber einige Webserver aus - besser als nix.

deltabrasil wrote:

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.

Ich vermute er hat keine Zahlen geliefert weil es die einfach nicht gibt. Solche Generalisierungen lassen schon erkennen mit wie wenig Fakten die Behauptung unterfüttert ist. Geld für Oracle-Lizenzen rauszuwerfen ist heute ein Glück theoretisch nur noch selten nötig. Ich glaube deltabrasil ist der erste, den ich treffe, der froh über den MySQL/Oracle-Deal ist

PostgreSQL und MySQL tun sich heute nicht mehr viel. In einigen Funktionen ist eins schneller als das andere aber sonst sind die beinahe gleichwertig: http://www.randombugs.com/linux/mysql-p … marks.html

Aber wie schon erwähnt, wurde kürzlich PostgreSQL von Version 8.3 auf 8.4 aktualisiert. Letztere scheint Performanceprobleme zu haben und niemand weiß genau ob es Konfigurationssache oder ein Fehler ist. Unter anderem hängen seitdem die Diffs um mehrere Minuten hinterher.

Vielleicht helfen auch noch die Munin-Stats um konstruktivere Kritik/Vorschläge abzugeben?

LarsF wrote:

Ich glaube deltabrasil ist der erste, den ich treffe, der froh über den MySQL/Oracle-Deal ist

hi, nur ne kleine "klarstellung".

oracle hat mysql nicht "gekauft", sondern SUN übernommen. und sun hat sich immer für opensource eingesetzt. daher kommen so "kleinigkeiten" wie openoffice, java, open solaris, und eben auch mysql (das hat sun aber irgenwann erworben).
was nun wirklich besser ist -mysql oder postgsql- mag ich nicht beurteilen. ob aber mysql bei oracle gut aufgehoben ist? ich hab da so meine bedenken.

lg
walter

Schön dass es hier so viele Computer-Freaks gibt, die angeregt über die Vor- und Nachteile verschiedener Datenbanken diskutieren.....

Potlatch ist übrigens immer noch unbrauchbar langsam: 'Request timed out'

speedpilgrim > µMap

speedpilgrim wrote:

Potlatch ist übrigens immer noch unbrauchbar langsam: 'Request timed out'

Ist natuerlich nicht wirklich eine Loesung, aber JOSM, Merkaator, bzw. Potlatch 2 sind zur Zeit moeglicherweise etwas schneller, da sie einen anderen Teil der API fuer downloads verwenden der nicht so betroffen ist. Der Upload duerft leider aber bei beiden ebenfalls langsam sein.

Vielen Dank für die Tips!
Natürlich kenne ich die anderen Möglichkeiten (bis auf Potlatch2, das ist mir wirklich neu gewesen). Mir ging es bei meinem Post aber um etwas viel Allgemeineres, deshalb möchte ich es etwas anders formulieren:

Zur Zeit ist der wichtigste Zugang zu OSM für den Normal-User (also den nicht-Nerd) nicht oder nur eingeschränkt funktionstüchtig!

OSM lebt vom Mitmachen von vielen, und die meisten davon lesen dieses Forum nicht. Wenn es eine technische Maßnahme gibt Potlatch zu beschleunigen, dann sollte diese schnell umgesetzt werden, sonst wird man diese Leute bald verlieren.

speedpilgrim > µMap

speedpilgrim wrote:

Vielen Dank für die Tips!
Natürlich kenne ich die anderen Möglichkeiten (bis auf Potlatch2, das ist mir wirklich neu gewesen). Mir ging es bei meinem Post aber um etwas viel Allgemeineres, deshalb möchte ich es etwas anders formulieren:

Zur Zeit ist der wichtigste Zugang zu OSM für den Normal-User (also den nicht-Nerd) nicht oder nur eingeschränkt funktionstüchtig!

OSM lebt vom Mitmachen von vielen, und die meisten davon lesen dieses Forum nicht. Wenn es eine technische Maßnahme gibt Potlatch zu beschleunigen, dann sollte diese schnell umgesetzt werden, sonst wird man diese Leute bald verlieren.

speedpilgrim > µMap

hi,
das problem ist da - es klemmt 🙁

aber es klemmt bei allen - potlatch / josm / merkaator / ...
mehr oder weniger.

es bringt jetzt aber garnix, das problem zu "umgehen" indem man z.b. potlatch etwas tuned; man muß die URSACHEN in den griff kriegen.
ich hoffe, dass die admins hier kräftig und erfolgreich dran arbeiten.

lg
walter

p.s. zur zeit leben wir alle in "interessanten zeiten" - was osm betrifft

wambacher wrote:

hi,
das problem ist da - es klemmt 🙁

aber es klemmt bei allen - potlatch / josm / merkaator / ...
mehr oder weniger.

es bringt jetzt aber garnix, das problem zu "umgehen" indem man z.b. potlatch etwas tuned; man muß die URSACHEN in den griff kriegen.
ich hoffe, dass die admins hier kräftig und erfolgreich dran arbeiten.

lg
walter

p.s. zur zeit leben wir alle in "interessanten zeiten" - was osm betrifft

stimmt, die Ursache muss gelöst werden.
Mit ist jedenfalls aufgefallen, dass es Abends viel schlimmer ist als tagsüber.

wambacher wrote:

es bringt jetzt aber garnix, das problem zu "umgehen" indem man z.b. potlatch etwas tuned; man muß die URSACHEN in den griff kriegen.

Naja, die _Ursache_ ist zu viele Leute versuchen zu viele Dinge fuer zu wenig Hardware.
Das kann man loesen in dem man entweder die User reduziert, die Hardware aufruetet, oder das System tuned.

An allen drei wird gearbeitet. Das erstere, in dem man Versucht einzelne User zu blocken die das System ueber die Gebuehr auslasten, aber das ist immer etwas problematisch, da man erst einmal sehen muss ob es legitim ist oder was die konsequencen ist. Die Hardware wird auch demnaechst wieder aufgeruestet, wobei die derzeitige Engstelle auf Grund von Punkt eins und drei eher dort geloest werden muss. Und drittens das tuning. Mit den letzten Software updates von Ubuntu 8.04 auf 10.04 und Postgresql 8.3 auf 8.4 haben sich irgendwo Performance regressions eingeschlichen die noch nicht bekannt sind. Das hat einiges der vorhanden Hardwarereserven aufgebraucht, so das Punk eins das ganze nun ueber den Berg geschoben hat. Der Software Punkt ist leider jedoch sehr komplex zu analysieren und zweitens muss man dann erst einmal die Software schreiben um dem dann entgegen zu wirken. Beides geht leider nicht so schnell.

efred wrote:

Mit ist jedenfalls aufgefallen, dass es Abends viel schlimmer ist als tagsüber.

Stimmt, Abends und am Sonntag sind schon immer die last spitzen gewesen. So das dort etwaige performance Probleme immer am deutlichsten zu merken sind.

Dieser Graphen zeigt das Problem recht anschaulich, wann die Server ueberlastet sind. Zusammen mit diesem Graphen der Zeigt wie viele Anfragen derzeit nicht bedient werden koennen und in den Ueberlaufschlangen warten muessen.

Ich hoffe aber natuerlich auch das das Problem so schnell wie moeglich geloest werden kann, da es zurzeit recht unbefriedigend ist :-S

P.S. ein weiterer Tipp fuer JOSM, der moeglicherweise funktioniert (habe ich noch nicht ausprobiert) ist das wenn Uploads nicht als ganzen Changeset hochgeladen werden, sondern man die Option fuer einzel uploads anclickt. Das laeuft dann wieder durch andere Warteschlangen, die nicht so ueberlastet sein sollten. Aber Bitte Bitte verwendet das nicht fuer grosse Uploads, sondern nur wenn man vielleicht ein paar POIs oder Strassen hochladen will, sonst ist das auch ganz schnell Ueberlastet und verursacht moeglicherweise noch groessere Probleme.

amm wrote:

Stimmt, Abends und am Sonntag sind schon immer die last spitzen gewesen. So das dort etwaige performance Probleme immer am deutlichsten zu merken sind.

Dieser Graphen zeigt das Problem recht anschaulich, wann die Server ueberlastet sind.

uiii... seit dieser Woche ist ja extrem, wie die Server ausgelastet sind... ufff... ich hoffe, das kriegt man schnell in den Griff...

Mit ist jedenfalls aufgefallen, dass es Abends viel schlimmer ist als tagsüber.

Stimmt, Abends und am Sonntag sind schon immer die last spitzen gewesen. So das dort etwaige performance Probleme immer am deutlichsten zu merken sind.

hi,
das erste, was mir aufgefallen ist: um 23-24:00 lokaler zeit ist schlagartig wieder "ruhe".
das sieht mir nach irgendeinem automatismus aus, der auf dem server BIS mitternacht amok läuft. oder macht der server selber was besonderes um mitternacht? backup? datenbank-tools, postgresql analyze, reboot? irgendwas oder irgendwer bereinigt das problem anscheinend zu dem zeitpunkt.
ich glaube nicht, das die sog. "bösen buben" gerade dann feierabend machen 😉

lg
walter

speedpilgrim wrote:

Zur Zeit ist der wichtigste Zugang zu OSM für den Normal-User (also den nicht-Nerd) nicht oder nur eingeschränkt funktionstüchtig!

Ich denke nicht, dass es kurzfristig eine Lösung gibt. Es sind einfach zuviele Benutzer. Am ehesten dürfte meiner Ansicht noch der Wechsel von Potlach zu Potlatch2 bringen (warum ist da plötzlich ein -t- dazugekommen?). Ich kann mir gut vorstellen, dass die andere Zugriffsart wesentlich weniger Serverbelastung produziert. Aber dazu müsste Potlatch2 so schnell wie möglich fertig werden.

Wyo

wyo wrote:

...
Am ehesten dürfte meiner Ansicht noch der Wechsel von Potlach zu Potlatch2 bringen (warum ist da plötzlich ein -t- dazugekommen?). ...

Der Online Editor hieß immer schon Potlatch (mit einem zweiten 't')
Siehe: http://wiki.openstreetmap.org/wiki/Potlatch

Edbert (EvanE)