Performance von Postgresql/postgis + umn mapserver

Hallo Leute,

ich habe eine Installation aus postgresql 8.4, postgis 1.5 und mapserver 6.2 mit OSM-Daten laufen. Funktioniert auch im Prinzip gut, leider bei unterirdischer Performance.
Ich habe postgres entsprechend diverser Tutorials getuned und meine SQL-Statements überprüft.
Jetzt stellt sich mir die Frage, ist meine Hardware zu schwach (Intel E6600 2x2,4Ghz, 4MB L2 Cache, 4GB DDR2 5300 ECC Ram, SATA2 HDD) oder ist die Kombination von Mapserver und Postgres nicht zu empfehlen. Top verrät mir, dass sowohl der Mapserver als auch Postgres massiv am rödeln sind, wenn lines und polygone on-the-fly generiert werden. Ich habe für diese Kombination (also mapserver + postgres) nach ner Caching-Lösung gesucht, bisher aber keine gefunden.
Ist mapnik ggf. besser geeignet mit mod_tiles für apache?

Ich bitte um Entschuldigung, wenn es etwas wirr ist, aber ich befinde mich gerade noch in der Orientierungsphase.

MfG jaboe

P.S.: sorry, gehört wohl nach postgis

Aus dem Bauch heraus: 4GB ist schlicht zu wenig RAM. Aber ohne zu sehen, was genau auf der Kiste passiert, ist das natürlich nur eine Annahme.


Andreas

Hast du Indexe richtig gesetzt? Wie sieht das explain für das verwendete SQL an? UMN und Postgres funktioniert eigentlich sehr gut, wobei 4GB recht wenig ist. Du kannst auch z.B. auch über das Mapfile tunen, z.B. maßstabsabhängige Darstellungen etc. Kommt natürlich auch drauf an, wieviel du on the fly für eine Ansicht renderst. Eventuell böte sich auch die Verwendung eines TileMapServices an. MapProxy bietet sowas oder auch der Geoserver.

Gruß Uwe

Hi,

ich habe die Indexe auf die Geometriespalten nochmal neu gesetzt, sie waren vorher auf B_TREE statt GIST gesetzt. Das nimmt auch geringfügig Last vom System. Ich habe interessehalber auch mal auf die DB mit qgis zugegriffen, was genauso langsam wie mit dem mapserver ist. Also liegt es offensichtlich auch nicht am Mapserver oder an der Mapfile, sondern am Postgres bzw. der Hardware, genauer gesagt scheint die CPU der Flaschenhals zu sein, denn der RAM wird nicht komplett ausgenutzt und auch nichts geswappt, während die CPU-Last zeitweise auf mehr als 90% bei mehreren parallelen Postgres-Prozessen hochgeht. Ich hab noch 'nen Rechner mit einem E8400 mit 2x3Ghz und 6MB L2-Cache und ebenfalls 4GB Ram rumstehen, damit werde ich mal eine Vergleichsinstallation machen.

MfG jaboe

Wie sind denn die Einstellungen für shared_mem und work_mem?

Gruß Uwe

Beide auf 128MB, falls Du mit shared_mem shared_buffers meinst.

MfG

Dann ist das für shared_buffers zu wenig.

Andreas

Ich hab shared_buffers mal auf 512MB hochgesetzt, was jedoch keine Veränderung gebracht hat. Aber wie gesagt, wenn ich mir die Ausgabe von top während eines Aufrufs eines Kartenausschnitts ansehe (bzw. Vergrößerung, Verkleinerung, Verschiebung), dann liegt der Verdacht nahe, dass der Prozessor einfach zu schwach ist.

MfG jaboe

Du solltest rausbekommen, was das für Abfragen sind und wie der Plan dafür ist. Ersteres kannst Du z.B. mit log_min_duration ermitteln, indem Du das passend setzt. Den Plan bekommst Du dann mit EXPLAIN. Dann kann man sehen, was genau abläuft und ob Indexe z.B. genutzt werden, wie gut die Cacherate ist etc.


Andreas

So, ich habe jetzt mal wie vorgeschlagen auto_explain verwendet, vielleicht könnt ihr damit was anfangen. Log_min_duration ist auf 5s gesetzt.

auto_explain - Pastebin.com

MfG

Grob quergelesen, keine Seq-Scans, also Indexe werden genutzt. Die Annahmen (rows) zu actual rows liegen weit auseinander, da scheint ein Analyse zu fehlen. Würde aber wohl nix am Plan bzw. der Zeit ändern.


Andreas

Ich hab erstmal einen Großteil der Polygonlayer (landuse mit so einem Kram wie Golfplätze, Militär, Erholung etc.pp.) entfernt, damit der MapProxy überhaupt 'ne Chance hat die Tiles zu cachen, ohne einen Timeout zu erzeugen.
Das ist zwar alles noch nicht wirklich optimal, aber ich denke, ich weiß jetzt wo die Probleme liegen, bzw. wie ich ihnen auf die Spur komme.
Daher erstmal danke - ich werde mich bestimmt bald wieder mit Problemen melden.

MfG jaboe