Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Hi, Stephan Wolff wrote: Ich hatte vermutet, dass meine verschachtelten Abfragen Schuld sind, aber Frederik hat mit dieser Beschreibung die Hauptursache getroffen. Ich habe den Zeitbedarf verschiedener SQL-Abfragen für größere Bereiche verglichen. Eine einfache Abfrage aller Punkte mit power=generator $ time psql -c select count(*) from planet_point where power=generator and way bounding_box ... benötigte in meinem Testbereich etwa 2,5 Minuten. Probier mal CREATE INDEX generator_index ON planet_osm_point using GIST(way GIST_GEOMETRY_OPS) WHERE power=generator; Der Request sollte nur wenige Minuten dauern. Danach muesste Deine Abfrage schneller sein. Somit bleibt zur Beschleunigung nur die Möglichkeit, eine eigene Datenbank vorab anzulegen. Kann man Osm2pgsql so konfigurieren, dass eine weitere Tabelle mitgepflegt wird oder muss man in regelmäßigen Abständen die gesamte Hauptdatenbank filtern? Der Query oben macht im Effekt das; er erzeugt einen bedingten Index, in dem *nur* alle power=generator-Nodes anhand ihrer Position verzeichnet sind. Das braucht zusaetzlich Platz (aber nicht viel - sind ja nicht so viele Nodes) und verlangsamt Updates (aber nicht viel), sollte Abfragen aber deutlich beschleunigen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Moin! Am 01.02.2011 19:41, schrieb Frederik Ramm: Stephan Wolff wrote: Der von mir erstellten Regeln führen leider zu sehr sehr langen Renderzeiten. [...] Ausserdem hat die Standard-Datenbank auch keine Indexe ausser dem geografischen; Deine Abfragen sind ja oft: select haufen krimskrams from planet_osm_line where power=line da wird dann ueber den GIN-Index alles rausgesucht, was in dem geogr. Bereich ist, und per table scan dann jede einzelne Linie angechaut, ob sie vielleicht power=line hat. Ich hatte vermutet, dass meine verschachtelten Abfragen Schuld sind, aber Frederik hat mit dieser Beschreibung die Hauptursache getroffen. Ich habe den Zeitbedarf verschiedener SQL-Abfragen für größere Bereiche verglichen. Eine einfache Abfrage aller Punkte mit power=generator $ time psql -c select count(*) from planet_point where power=generator and way bounding_box ... benötigte in meinem Testbereich etwa 2,5 Minuten. Komplexe, geschachtelte select-Anweisungen $ time psql -c select sum(output) from (select haufen krimskrams from planet_point where power=generator and way bounding_box ... waren nur wenige Sekunden langsamer. Auch die Position des geogr. Filters in der inneren oder in der äußeren select-Anweisung machten keinen Unterschied. Somit bleibt zur Beschleunigung nur die Möglichkeit, eine eigene Datenbank vorab anzulegen. Kann man Osm2pgsql so konfigurieren, dass eine weitere Tabelle mitgepflegt wird oder muss man in regelmäßigen Abständen die gesamte Hauptdatenbank filtern? Vielen Dank auch an meinen Namensvetter Stephan und Tim für die hilfreichen Kommentare. Jetzt verstehe ich besser, wie Mapnik die Karten rendert. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Hallo, Mapnik baut um deine Abfrage noch eine Bounding Box in die Where-Klause, in etwa in der Art: AND way ST_Transform(ST_SetSRID(ST_MakeBox2D(ST_Point(13.5333,50.95),ST_Point(13.9333,51.15)),4326),900913)) So kannst du dann deine Abfragen auch testen (EXPLAIN). Generell sind die Operation in der Select-Klausel wohl eher unkritisch, während die Bedingungen in der Where-Klausel kritisch sind und diese müssen unbedingt auf einen Index zugreifen, was bei die aber der Fall zu sein scheint. Grüße Tim Am 03.02.2011 01:45, schrieb Stephan Wolff: Am 02.02.2011 00:01, schrieb Kolossos: Vielleicht wäre es ja eine Idee erstmal einen temporären View auf power=* innerhalb der BBOX zu kreieren und dann darauf in den folgenden 20 Abfragen auf diesen stark reduzierten Datensatz zuzugreifen. Dafür müsste man vermutlich die Syntax des mapnik-styles um einen Parameter erweitern. Leider verstehe ich nicht, wie aus den x,y,z-Koordinaten und der SELECT-Anweisung in der xml-Datei eine SQL-Abfrage mit geografischem Filter entsteht. Erstaunlicherweise werden manche Tiles nicht gerendert, obwohl sie keine oder sehr wenige Elemente mit power=* beinhalten (z.B /tiles/powermap/10/536/328.png), während andere Tiles mit viel mehr Objekten berechnet werden (z.B. /tiles/powermap/10/537/327.png). Scheinbar werden viel größere Bereiche als ein Tile geografisch selektiert. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Am 02.02.2011 00:01, schrieb Kolossos: Vielleicht wäre es ja eine Idee erstmal einen temporären View auf power=* innerhalb der BBOX zu kreieren und dann darauf in den folgenden 20 Abfragen auf diesen stark reduzierten Datensatz zuzugreifen. Dafür müsste man vermutlich die Syntax des mapnik-styles um einen Parameter erweitern. Leider verstehe ich nicht, wie aus den x,y,z-Koordinaten und der SELECT-Anweisung in der xml-Datei eine SQL-Abfrage mit geografischem Filter entsteht. Erstaunlicherweise werden manche Tiles nicht gerendert, obwohl sie keine oder sehr wenige Elemente mit power=* beinhalten (z.B /tiles/powermap/10/536/328.png), während andere Tiles mit viel mehr Objekten berechnet werden (z.B. /tiles/powermap/10/537/327.png). Scheinbar werden viel größere Bereiche als ein Tile geografisch selektiert. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
On 03.02.2011 01:45, Stephan Wolff wrote: Objekten berechnet werden (z.B. /tiles/powermap/10/537/327.png). Scheinbar werden viel größere Bereiche als ein Tile geografisch selektiert. Der Server rechnet Metatiles. Das sind in der Regel 64 einzelne Tiles die am Stück gerechnet und gespeichert werden. Dazu kommt noch ein wenig Überlappung an den Rändern damit die Schnittgrenzen zusammenpassen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Performanceprobleme bei Mapnik/SQL
Moin, in meinen ersten Versuchen mit Mapnik habe ich eine Karte der elektrischen Infrastruktur erstellt. Die Karte zeigt Stromleitungen mit Kodierung von Spannung und Frequenz, Kraftwerke mit Energiequelle und Leistung sowie Umspannwerke. Ein Kartenausschnitt ist unter http://toolserver.org/~osm/styles/?zoom=11lat=54.2584lon=10.03051layers=F0FFF0FFFB000T erreichbar, der Mapnik-style unter http://svn.toolserver.org/svnroot/p_osm/styles/powermap/ . Der von mir erstellten Regeln führen leider zu sehr sehr langen Renderzeiten. Zoomlevel 10 können nicht in erträglicher Zeit berechnet werden. Offenbar führen die komplexen SQL-Abfragen zur Auswertung nummerischer Zusatzdaten zu diesen Problemen. Ich habe versucht, die Regeln zu vereinfachen, aber auch die neue Version (http://toolserver.org/~seawolff/powerN.xml) ist sehr langsam. Wer kann mir Tipps zur Verbesserung der Performance geben? Gibt es Beispiele für die Auswertung nummerischer tags für Mapnik? Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Am 1. Februar 2011 17:17 schrieb Stephan Wolff s.wo...@web.de: Wer kann mir Tipps zur Verbesserung der Performance geben? Gibt es Beispiele für die Auswertung numerischer tags für Mapnik? ich finde dieses Thema auch sehr interessant, vor allem die Frage, ob die expliziten Typumwandlungen mit cast evtl. zu einer spürbaren Verlangsamung führen. Hat da jemand schonmal Versuche angestellt? Wie kostspielig sind order-by-Befehle? (Hier habe ich den Verdacht, dass es wie ich es mir gedacht hatte, sowieso nicht funktioniert in Mapnik: auch wenn ich mit order by die Reihenfolge versuche vorzugeben entspricht das Ergebnis nicht dem erwarteten (bzw. nicht der Reihenfolge, die derselbe Befehl in psql erzeugt. Hat dazu jemand evtl. einen Tip?) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Hallo, Stephan Wolff wrote: Der von mir erstellten Regeln führen leider zu sehr sehr langen Renderzeiten. So komplizierte Regeln sind dann halt schon ein gutes Argument fuer eine eigene Datenbank, in der man diese Sachen, die man staendig braucht, ueber Trigger vorberechnen laesst. Ausserdem hat die Standard-Datenbank auch keine Indexe ausser dem geografischen; Deine Abfragen sind ja oft: select haufen krimskrams from planet_osm_line where power=line da wird dann ueber den GIN-Index alles rausgesucht, was in dem geogr. Bereich ist, und per table scan dann jede einzelne Linie angechaut, ob sie vielleicht power=line hat. In einer eigenen Datenbank koenntest Du einen kombinierten geografischen Index mit power=line machen, dann ginge das schneller. (Eventuell kannst Du die toolserver-Betreiber ja zu so einem Index ueberreden.) Alternativ koennte man auch power=line in die planet_osm_roads-Tabelle kopieren lassen, in der hat man normal die Autobahnen und andere grossraeumige Sachen, da ist der Zugriff schneller, weil weniger Kleinkram drin liegt. Ansonsten rate ich dazu, das Loggin einzuschalten und mittels Verstand und/oder der Skripte in applications/rendering/mapnik/utils genauer herauszufinden, welche der Abfragen die Probleme machen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Am 1. Februar 2011 19:09 schrieb M∡rtin Koppenhoefer dieterdre...@gmail.com: (Hier habe ich den Verdacht, dass es wie ich es mir gedacht hatte, sowieso nicht funktioniert in Mapnik: auch wenn ich mit order by die Reihenfolge versuche vorzugeben entspricht das Ergebnis nicht dem erwarteten (bzw. nicht der Reihenfolge, die derselbe Befehl in psql erzeugt. Hat dazu jemand evtl. einen Tip?) den Verdacht ziehe ich zurück, entschuldigt bitte. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Moin! Am 01.02.2011 19:41, schrieb Frederik Ramm: Stephan Wolff wrote: Der von mir erstellten Regeln führen leider zu sehr sehr langen Renderzeiten. So komplizierte Regeln sind dann halt schon ein gutes Argument fuer eine eigene Datenbank, in der man diese Sachen, die man staendig braucht, ueber Trigger vorberechnen laesst. Ich wollte doch nur eine einfache Overlaykarte basteln und hatte schon Mühe genug, mich in die Mapnik-Konfiguration einzuarbeiten. Jetzt soll ich auch noch eine Datenbank erstellen und pflegen ;-) Ausserdem hat die Standard-Datenbank auch keine Indexe ausser dem geografischen; Deine Abfragen sind ja oft: select haufen krimskrams from planet_osm_line where power=line da wird dann ueber den GIN-Index alles rausgesucht, was in dem geogr. Bereich ist, und per table scan dann jede einzelne Linie angechaut, ob sie vielleicht power=line hat. Ich habe leider nicht genau verstanden, wie das render-Skript die Abfragen zusammensetzt. Wenn erst die Datenbankobjekte zuerst geografisch selektiert werden und danach der Test auf power=line stattfindet, dann sollte haufen krimskrams nur für wenige bis wenige hundert Objekte (je nach Zoomlevel) ausgeführt werden. Laut tagwatch gibt es in Deutschland knapp 12000 mal power=line. Die Standardkarte ruft select * from planet_line where power='line' zusammen mit vielen weiteren Abfragen problemlos auf. In einer eigenen Datenbank koenntest Du einen kombinierten geografischen Index mit power=line machen, dann ginge das schneller. (Eventuell kannst Du die toolserver-Betreiber ja zu so einem Index ueberreden.) Alternativ koennte man auch power=line in die planet_osm_roads-Tabelle kopieren lassen, in der hat man normal die Autobahnen und andere grossraeumige Sachen, da ist der Zugriff schneller, weil weniger Kleinkram drin liegt. Wenn das die einzige, praktikable Lösung ist, muss ich darüber nachdenken, ob und wie der Vorschlag umsetzbar ist. Ansonsten rate ich dazu, das Loggin einzuschalten und mittels Verstand und/oder der Skripte in applications/rendering/mapnik/utils genauer herauszufinden, welche der Abfragen die Probleme machen. Das habe ich getan. Ganz trivial sind auch Tests in psql nicht, da die Rechenzeit stark davon abhängt, ob dieselben Daten zuvor mit einer anderen Abfrage selektiert wurden. Teilweise war die zweite, ähnliche Abfrage um einen Faktor 10 schneller. Zweifellos sind die geschachtelten Aufrufe select haufen krimskrams from (select nochmehr krimskrams from ...) für power=line und power=generator langsam. Ich weiß leider nicht, wie ich sie bei gleicher Funktion beschleunigen kann. Viele Grüße, Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Performanceprobleme bei Mapnik/SQL
Hallo, der hstore auf dem Toolserver ist meines Wissens indiziert, genutzt wird dieser Index bei einer eher lokalen Abfrage aber wohl erstmal nicht. Vielleicht wäre es ja eine Idee erstmal einen temporären View auf power=* innerhalb der BBOX zu kreieren und dann darauf in den folgenden 20 Abfragen auf diesen stark reduzierten Datensatz zuzugreifen. Dazu gab es wohl schonmal irgendwie Diskussionen[1]. Keine Ahnung inwieweit Mapnik das aber unterstützt. Grüße Tim [1]http://www.mail-archive.com/talk-de@openstreetmap.org/msg58867.html Am 01.02.2011 19:41, schrieb Frederik Ramm: Hallo, Stephan Wolff wrote: Der von mir erstellten Regeln führen leider zu sehr sehr langen Renderzeiten. So komplizierte Regeln sind dann halt schon ein gutes Argument fuer eine eigene Datenbank, in der man diese Sachen, die man staendig braucht, ueber Trigger vorberechnen laesst. Ausserdem hat die Standard-Datenbank auch keine Indexe ausser dem geografischen; Deine Abfragen sind ja oft: select haufen krimskrams from planet_osm_line where power=line da wird dann ueber den GIN-Index alles rausgesucht, was in dem geogr. Bereich ist, und per table scan dann jede einzelne Linie angechaut, ob sie vielleicht power=line hat. In einer eigenen Datenbank koenntest Du einen kombinierten geografischen Index mit power=line machen, dann ginge das schneller. (Eventuell kannst Du die toolserver-Betreiber ja zu so einem Index ueberreden.) Alternativ koennte man auch power=line in die planet_osm_roads-Tabelle kopieren lassen, in der hat man normal die Autobahnen und andere grossraeumige Sachen, da ist der Zugriff schneller, weil weniger Kleinkram drin liegt. Ansonsten rate ich dazu, das Loggin einzuschalten und mittels Verstand und/oder der Skripte in applications/rendering/mapnik/utils genauer herauszufinden, welche der Abfragen die Probleme machen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
