Performance Tuning?

Hallo,

mein rechner meckert beim Import von über 5000 Zeilen mit Punktgeometrien rum. Speicher voll oder so ähnlich ??? Ich sollte allerdings 120.000 Zeilen importieren.

Nun habe ich mir die postgresql.conf vorgenommen und sehe, dass die zeile

“effective_cache_size” = 128 MB mit einer # auskommentiert ist.

“shared_buffers” ist mit 12MB angegeben.

Kann mir jemand Tipps geben, wie ich Postgresql/postgis konfigurieren muss? Habe leider nur 2 GB RAM zur Verfügung.

lg Markus

Ist das ein dedizierter Server, nur für PG?

Falls ja, würde ich mit 512 MByte für shared_buffers und 1,5 gbyte für effective_cache_size starten.

Und ja, in Zukunft nicht a la ‘Fehler lautet so ähnlich’, sondern hier mal dem Guttenberg in Dir freien Lauf lassen und die Fehlermeldung einfach reinkopieren. Kann doch nicht so schwer sein, oder?

Andreas

Da steht ja sogar normalerweise automatisch dran wo es herkommt, brauchst also gar keine Angst zu haben…
In der Tat sollten 120000 Punkte selbst bei dieser HW kein allzu großes Problem sein. Allerdings können mehrere Fehlerquellen in Frage kommen. Wie liest du die Daten denn ein?

Gruß Uwe

Hallo Andreas, Hallo Uwe,

danke für die schnellen Antworten.

@Andreas:
Es handelt sich um keinen Server sondern um meinen Privat-PC. Wird das shared_buffer und cache_size dann für PG reserviert, oder stehen die Ressourcen für andere Programme weiter zur Verfügung solange PG im Leerlauf ist? Oder muss ich PG dann stoppen um die Ressourcen für andere Progs freizugeben?

@Uwe
Für den Import habe ich mir ein php-script zusammengefrickelt. Die Punktgeometrie habe ich hier als long-lat in Textform. Beim Import wird also aus WKT WKB.

@all
ist bei euch “effective_cache_size” nach der installation auch auskommentiert? Die Raute (#) steht doch für Kommentare, oder?

lg Markus

shared_buffer wird echt allokiert, effective_cache_size ist für den Planner nur ein Hinweis, wieviel Cache (shared_buffer + OS-Cache) auf dem System ist, da wird aber nix allokiert.

Andreas

Wenn das auskommentiert ist, wird der Default-wert gesetzt.
Wie commitest du denn die Daten? Einzeln oder als eine Transaktion?

Grüßle Uwe

PS: Es fehlt immer noch eine aussagekräftige Fehlermeldung… :wink:

die sache ist die: genau genommen handelt es sich um UPDATE. Das skript erzeugt mir 120.000 Zeilen mit jeweils einem

“update tabelle set the_geom = fromtext(x y) where id=1”
“update tabelle set the_geom = fromtext(x y) where id=2”

lg

ps: fehlermeldung kann ich derzeit keine liefern. kriege seit config-änderung den server nicht mehr gestartet.

UPDATEs … langsamer kann man die Sache echt nicht angehen :frowning:

du meinst also die daten in eine zweite tabelle mit insert?

Ich meine, das man sicherlich zuerst einmal schauen müsste, was das zu lösende Problem ist.
Aber einzelne UPDATEs zu feuern, ggf. auch noch in einzelnen Transaktionen, mit nicht vorbereiteten Anfragen, dürfte im Endeffekt sehr sehr langsam sein.

Dein SQL dürfte irgendwie nicht funktionieren. Ich würde das so regeln (wenn denn ein Update sein muß):

update tabelle set 
  the_geom = st_geomfromtext('(POINT'||x||' ' y||')',4326) where the_geom is Null

oder so ähnlich. 4326 ist die gängige SRID für Lat/Lon, es gibt auch andere. Falls deine Geometriespalte ohne SRID angelegt ist mußt du da -1 schreiben. Du kannst das auch über einen Trigger lösen falls du z.B nicht weißt welche Koordinatensystem deine Punkte haben, oder du machts es gleich beim Insert der Daten.

Gruß Uwe

Leute, vielen Dank für eure Antworten. Das Problem ist gelöst :slight_smile: freu freu

shared_buffer verdoppelt auf 24 MB. Bei über 24 MB lässt sich der Server nicht mehr starten. Jetzt schluckt der Server alle 120.000 Update-Befehle. Rechnet zwar einige Minuten unter Höchstlast, aber Hauptsache es geht :slight_smile:

Übrigens: effective_cache_size muss auskommentiert sein. zumindest bei mir. ohne # geht sonst gar nix mehr

ps: query funzt schon. habe als srid 4326. gibt es eigentlich noch andere srid, welche die ganze welt abdecken?

lg und danke nochmals

Nun, ich kann mir gut denken, warum mehr als 24 MB bei dir nicht funktionieren.
Wirf doch bitte einen Blick in das Logfile der Datenbank, dort steht die Fehlermeldung.

Danach ändere das Shared Memory deines Betriebssystems.

Schau mal in die Tabelle public.spatial_ref_sys :wink: Du wirst staunen was es da alles gibt :wink:

Im Ernst: Für weltweite Datensätze ist WGS84 bzw epsg:4326 als winkelbasiertes System schon richtig. 900913 bietet sich vielleicht an, wenn man viel mit OSM oder Google arbeitet. UTM oder Gauss-Krüger sind als projizierte Koordinatensysteme auf m-Basis eher für kurze Distanzen geeignet.

Gruß Uwe

Da spricht der Experte!

Hälst du darüber mal einen Vortrag? Auf der deutschen PostgreSQL Konferenz vielleicht?

Leider keine logs verfügbar. ist in standardkonfig anscheindend off. Du meinst am Kernel Shared Memory schrauben?


@Uwe:
Über 900913 find ich nichts. Wird das von OSM und Google verwendet? Wenn ich eine 4326-Koordinate bei Google Maps eingebe, kommt nicht der richtige Standort.

http://spatialreference.org/ref/epsg/900913/

Und UTM ist nicht global? Ich dachte die Abkürzung steht für Universal, oder so???

lg

Ja, das meine ich.

Da wäre ich nicht nur dafür, sondern auch Zuhörer :wink:

Andreas

@ads, akretschmar: Haus steht, umgezogen bin ich, die Chancen steigen :wink:

@Markus_: UTM und GK sind in gewissen Sinne schon global, aber in Zonen eingeteilt, die in Streifen angeordnet sind und ein sog. false easting verwenden. Deswegen kann man die Koordinaten aus nebeneinader liegenden Streifen nicht einfach aneinander hängen. Bei GK gibt z.B. die erste Zahl der x-koordinate (2,3,4,5 in D) nur die Nummer des Streifens an und ist keine reele Koordinate. Du kannst dir das mal zusammengoogeln, da sind dann meist auch Zeichnungen dabei die das etwas deutlicher machen.

Der Link zur Projektion geht. Grund für diese Sache ist, das Goggle wohl gerne eine ideal runde Welt haben möchte.

Gruß UWe