Potlatch scheint gar nicht mehr zu reagieren…ist das das Ende??
speedpilgrim > µMap
EDIT: Nein, hat nur 10min gedauert 
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…
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/openstreetmap/norbert.openstreetmap/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.
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-postgresql-benchmarks.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?
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
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
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.
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.
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.
uiii… seit dieser Woche ist ja extrem, wie die Server ausgelastet sind… ufff… ich hoffe, das kriegt man schnell in den Griff…
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
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
Der Online Editor hieß immer schon Potlatch (mit einem zweiten ‘t’)
Siehe: http://wiki.openstreetmap.org/wiki/Potlatch
Edbert (EvanE)