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.
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?
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?
@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?
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.
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.
Leute, vielen Dank für eure Antworten. Das Problem ist gelöst 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
Ü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?
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 Du wirst staunen was es da alles gibt
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.
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.
@ads, akretschmar: Haus steht, umgezogen bin ich, die Chancen steigen
@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.