SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

berlingo69 · 2014-05-12 13:54:03

Ersteinmal ein liebes ...
Hallo an die deutsche OSM Foren-Gemeinde,
ich werde mich wohl zukünftig etwas mehr mit OSM auseinandersetzen.
Mein Ziel ist es, ein eigenen Tiles-Server aufzusetzen inkl. Nominatim (oder Vergleichbares) für die Adresss-Geokodierung.

Begonnen habe ich mit der Anleitung SWITCH2OSM, für Ubuntu 12.04(.04 LTS) und sie verlief bis zu einem gewissen Punkt ziemlich reibungslos.
Hier oder da musste ich etwas nachschlagen und aktuallisieren/nachinstallieren.

Nun bin ich beim importieren der Daten angekommen....

Reading in file europe-latest.osm.pbf
Processing: Node(1205159k 160.1k/s), Way(148459 1.11k/s) Relation(42290 5.68/s)...

und .... es kam zu einen Fehler, mit nachfolgenden Abbruch des Import, grummel.

osm2pgsql: PolygonBuilder.cpp:261: geos::geograph::EdgeRing* geos::operation::overlay::PolygonBuilder::findShell(std::veector<geos::operation::overlay::MinimalEdgeRing*>*): Assertion 'shellCount <= 1' failed

Meine Kenntnisse in dem Bezug auf Linux sind etwas veraltet, ich war daher aucht recht überrascht wie gut bis jetzt alles verlief.
Laut google ist dieses ein bekannter BUG der bereits behoben wurde, nur wie komme ich an die aktuelle Version?
Bei einigen Benutzer lass ich etwas von src-Code runterladen und selbst kompilieren, sicher bin ich mir aber nicht.
Im Laufe der Installation hatte ich ja bereits Pakete rungeladen und kompiliert und anschließend installiert, das Ganze aber nur nach Anleitung.
Dieser Fehler bringt mich aber fast schon zu Verzweiflung.

Über jeglich Unterstützung würde ich mich natürlich freuen...

Last edited by berlingo69 (2014-05-12 14:56:35)

wambacher · 2014-05-12 14:02:07

berlingo69 wrote:

Dieser Fehler bringt mich aber fast schon zu Verzweiflung.
Über jeglich Unterstützung würde ich mich natürlich freuen...

falls das wirklich an osm2pgsql liegen sollte: selber maken, siehe https://wiki.openstreetmap.org/wiki/Osm … rom_source

hab ich auch gemacht, da ich einige kleine Änderungen eingebaut habe. Musst beim Installieren nur darauf achten, dass das bereits installierte osm2pgsql auch wirklich ersetzt wird (machte bei mir am Anfang Problemchen). Oder vorher das Paket löschen.

Gruss
walter

Last edited by wambacher (2014-05-12 14:03:26)

berlingo69 · 2014-05-13 06:37:27

Hallo Walter, vorab, danke für deine Unterstützung...

falls das wirklich an osm2pgsql liegen sollte: ...

Es liegt nicht direkt an osm2pgsql, eher an den verwendeten Bibliotheken von postgis, siehe u.a. hier: http://gis.stackexchange.com/questions/ … postgresql

...selber maken, siehe https://wiki.openstreetmap.org/wiki/Osm … rom_source
... Musst beim Installieren nur darauf achten, dass das bereits installierte osm2pgsql auch wirklich ersetzt wird (machte bei mir am Anfang Problemchen). Oder vorher das Paket löschen.

Ich habe den dort beschrieben Weg mir mal angeschaut, im Grunde gleicht dieses ja dem Weg auf switch2osm. Lediglich das Kompilieren von osm2pqsql ist hier ein gesonderter Part.
Ärgerlicherweise tritt dieser Fehler serh spät, am Ende des Datenimports/-generierung auf. Das Ergebnis eine Veränderung an der Installation ist erst "Tage später" erkennbar.
Ich komme mir vor wie ein Labroant, mit unendlich viel Zeit.

Aus diesem Grund werde ich mich ersteinmal mit der Perfomance aus einandersetzen, das ganze System ist auf eine Virtueller-PC mit einer Zuteilung von 2 Quad-Core-CPUs a 3.4 GHz und 4 GB Arbeitsspeicher.
Der Festplattenspeicher liegt in einem Hochgeschwindigkeits-(..?!) SAN. Starten kann ich osm2pqsql nur im "--slim" Modus, ich drifte aber ab, sollte ich vieleicht ein neuen Thread aufmachen ... ?

Gruß...
Erik

Last edited by berlingo69 (2014-05-13 06:40:08)

wambacher · 2014-05-13 07:22:19

berlingo69 wrote:

Es liegt nicht direkt an osm2pgsql, eher an den verwendeten Bibliotheken von postgis, siehe u.a. hier: http://gis.stackexchange.com/questions/ … postgresql

Wenn du meinst - mir sieht das ein wenig spekulativ aus. Nun denn, hier ist meine Version:

Ganz normal über die Paketverwaltung (synaptic oder apt-get) installiert.

Mein letzter Import des Full-Planets war am 15.10.2013 unter ubuntu 13.04 oder 13.10 und lief - natürlich - reibungslos.

osm2pgsql --verbose -c -s --style wno.style -d osm -l -U postgres \
          --hstore-all --hstore-add-index \
          --number-processes 8 \
          --keep-coastlines \
          -G \
          -C 4000 \
          /data4/import/tmp/planet-131009.osm.bz2

Gruss
walter

Ach ja: Muß es am Anfang gleich der Full Planet sein?

Last edited by wambacher (2014-05-13 07:26:41)

berlingo69 · 2014-05-13 08:15:40

Hallo Walter,
ich muss mich erst wieder einlebe in die Linux-Welt (inkl. OSM), von daher ist so manches von mir noch spekulativ...sorry.

postgres@osm-server:~$ dpkg -l | grep libgeos
ii  libgeos-3.2.2                            3.2.2-3ubuntu1                    Geometry engine for Geographic Information Systems - C++ Library
ii  libgeos-c1                               3.2.2-3ubuntu1                    Geometry engine for Geographic Information Systems - C Library
ii  libgeos-dev                              3.2.2-3ubuntu1                    Geometry engine for GIS - Development files
postgres@osm-server:~$

Deine 3.3.x Version beinhaltet laut einem gestern gefundenem Posting (wo auch immer das war) die BUG Korrektur.
Ich gehe mal daran und werde versuchen die Kernkomponenten zu vergleichen, was habe ich und was ist aktuell.
Entsprechend werde ich dann Versuchen die aktuelle Versionden über apt-get zu installieren.
Mal sehen ob ich das mit meinen (noch) veralteten Kenntnissen hinbekommen, oder ob ich die src herunterlade und neugeneriere (kompilieren/konfigurieren/installieren).

Es sah alles so einfach aus

berlingo69 · 2014-05-13 08:17:35

Ach ja: Muß es am Anfang gleich der Full Planet sein?

Ich importiere ... europe-latest.osm.pbf.

wambacher · 2014-05-13 08:34:26

berlingo69 wrote:

Ach ja: Muß es am Anfang gleich der Full Planet sein?
Ich importiere ... europe-latest.osm.pbf.

jau, wer lesen kann (und das auch tut), ist echt im Vorteil.

wambacher · 2014-05-13 08:42:09

berlingo69 wrote:

Mal sehen ob ich das mit meinen (noch) veralteten Kenntnissen hinbekommen, oder ob ich die src herunterlade und neugeneriere (kompilieren/konfigurieren/installieren).
Es sah alles so einfach aus

Linux ist einfach - nur will das kein Windows-Anwender glauben.

apt-get install libgeos-dev sollte es bringen.

eventuell noch vorher?/nachher?:

apt-get update
apt-get upgrade

Falls er fragt, ob das OS (12.04 --> 14.04) hochgezogen werden soll, erst mal verneinen.

Gruss
walter

berlingo69 · 2014-05-13 09:12:14

root@osm-server:~# apt-get install libgeos-dev
....
Die folgenden zusätzlichen Pakete werden installiert:
  libgeos-3.2.2 libgeos-c1
Vorgeschlagene Pakete:
  libgdal-doc
Die folgenden NEUEN Pakete werden installiert:
  libgeos-3.2.2 libgeos-c1 libgeos-dev
0 aktualisiert, 3 neu installiert, 0 zu entfernen und 0 nicht aktualisiert.
...

Und wieder nur die 3.2.2 Version, irgendwie schaue ich nicht in das richtige Paket-Repository.
(siehe auch http://packages.ubuntu.com/precise/libgeos-dev)

Werde mal weiter suchen, nach ...: install precise libgeos-dev 3.3.3 src

Theodin · 2014-05-13 12:06:05

Precise (12.04) hat nur die alte 3.2.2er Version:
http://packages.ubuntu.com/search?suite … ibgeos-dev
Da brauchst du ein PPA, ich habe gerade dieses gefunden, weiß aber nicht ob es das richtige ist. Immerhin hat es das gewünschte Paket:
https://pgdgbuild.dus.dg-i.net/repos/apt/

berlingo69 · 2014-05-13 12:26:17

So gefunden, ich habe die /etc/apt/source.list erweitert um ...

deb http://de.archive.ubuntu.com/ubuntu/ saucy universe
deb-src http://de.archive.ubuntu.com/ubuntu/  saucy universe
deb http://de.archive.ubuntu.com/ubuntu/ saucy-updates universe
deb-src http://de.archive.ubuntu.com/ubuntu/ saucy-updates universe

Dann das alte Paket entfernt und das neue Paket hinzugefügt ...

sudo apt-get purge --auto-remove libgeos-dev
apt-get install libgeos++-dev

ich glaube das war es (wenn ich mich recht erinnere).

Walter, ich bin jetzt auf deinem Stand ...

ii  libgeos++-dev                            3.3.3-1.1ubuntu1                  Geometry engine for GIS - C++ development files
ii  libgeos-3.3.3                            3.3.3-1.1ubuntu1                  Geometry engine for Geographic Information Systems - C++ Library
ii  libgeos-c1                               3.3.3-1.1ubuntu1                  Geometry engine for Geographic Information Systems - C Library
ii  libgeos-dev                              3.3.3-1.1ubuntu1                  Geometry engine for GIS - Development files

Dann wurde osm2pgsql nochmal entfernt und neu installiert, lt. switch2osm (10.04).
Der VM wurde mehr Speicher zugewiesen: 16 GB

Der erneute Import wurde wie folgt gestartet...

sudo nice -n -10 sudo -u $USER osm2pgsql -d gis -C 20000 --number-processes 8 europe-latest.osm.pbf

Die Node (1205159k 1274.0k/s) haben den kompletten Speicher gefressen, Way(aktuell 9665k von 148459) und die Relation werden nun über den Swap (6 GB) bedient.
Das sieht aber nicht gut aus ... 3108 von 5117 MB sind nur noch frei, grummel...
Ich habe angenommen, das nur die Nodes im Speicher gehalten werden, der Rest wird berechnet und gespeichert?!?? Fehlannahme...
Mal sehen ob ich noch irgendwo weitere 16 GB herbekomme...

wambacher · 2014-05-13 16:34:18

berlingo69 wrote:

Walter, ich bin jetzt auf deinem Stand ...

ii  libgeos++-dev                            3.3.3-1.1ubuntu1                  Geometry engine for GIS - C++ development files
ii  libgeos-3.3.3                            3.3.3-1.1ubuntu1                  Geometry engine for Geographic Information Systems - C++ Library
ii  libgeos-c1                               3.3.3-1.1ubuntu1                  Geometry engine for Geographic Information Systems - C Library
ii  libgeos-dev                              3.3.3-1.1ubuntu1                  Geometry engine for GIS - Development files

sieht gut aus.

Dann wurde osm2pgsql nochmal entfernt und neu installiert, lt. switch2osm (10.04).
Der VM wurde mehr Speicher zugewiesen: 16 GB
Der erneute Import wurde wie folgt gestartet...
sudo nice -n -10 sudo -u $USER osm2pgsql -d gis -C 20000 --number-processes 8 europe-latest.osm.pbf

20 GB Cache bei 16 GB Vmem? nimm 10000

Die Node (1205159k 1274.0k/s) haben den kompletten Speicher gefressen, Way(aktuell 9665k von 148459) und die Relation werden nun über den Swap (6 GB) bedient.
Das sieht aber nicht gut aus ... 3108 von 5117 MB sind nur noch frei, grummel...
Ich habe angenommen, das nur die Nodes im Speicher gehalten werden, der Rest wird berechnet und gespeichert?!?? Fehlannahme...
Mal sehen ob ich noch irgendwo weitere 16 GB herbekomme...

nicht nötig:

füge noch diese Option hinzu: --flat-nodes ... mit beliebigen Filenamen. Dann legt osm2pgsql die Nodes nicht in der DB ab und performiert erheblich besser.

Achtung: Das File ist wichtig und wird später bei jedem Update der DB gebraucht. Nicht löschen! Beim Full-Planet ist das Teil 22 GB groß, Europa dürfte "etwas" kleiner sein. ~10 GB?

Gib den restlichen Speicher besser an Postgresql (in postgresql.conf anpassen, ist aber nicht so einfach); SSD würden auch viel bringen.

Mein Planet-Import hat übrigens 5 Tage gedauert (8-Core 4 GHz, 32 GB Mem, 500 GB Disk für die OSM-DB)

Gruss
walter

SimonPoole · 2014-05-13 16:48:42

wambacher wrote:

20 GB Cache bei 16 GB Vmem? nimm 10000

Noe.

Der Hinweis auf switch2osm.org ist nicht aus Blödelei da, es ist sogar so das aktuell (da wir ja mehr Nodes haben als die Anleitung geschrieben wurde) man deutlich mehr nehmen sollte (um den Jahreswechsel war das 18000). Natürlich fängt die Maschine bei zu wenig Memory an zu swappen (und deshalb sollte genügend Swap konfiguriert sein), dass ist aber immer noch deutlich schneller als ein zu kleiner Nodecache.

PS: 5 Tage ist deutlich zu lang, siehe z.B. http://wiki.openstreetmap.org/wiki/Osm2 … 28stock.29

Last edited by SimonPoole (2014-05-13 16:52:55)

amm · 2014-05-13 17:15:43

berlingo69 wrote:

Der erneute Import wurde wie folgt gestartet...
sudo nice -n -10 sudo -u $USER osm2pgsql -d gis -C 20000 --number-processes 8 europe-latest.osm.pbf
Die Node (1205159k 1274.0k/s) haben den kompletten Speicher gefressen, Way(aktuell 9665k von 148459) und die Relation werden nun über den Swap (6 GB) bedient.
Das sieht aber nicht gut aus ... 3108 von 5117 MB sind nur noch frei, grummel...
Ich habe angenommen, das nur die Nodes im Speicher gehalten werden, der Rest wird berechnet und gespeichert?!?? Fehlannahme...
Mal sehen ob ich noch irgendwo weitere 16 GB herbekomme...

Fehlt hier die --slim option? Ohne slim versucht osm2pgsql den gesamten Import im ram durchzufuehren. Das ist bei den heutigen Planet groessen ohne gigantische Mengen an RAM nicht mehr moeglich. Wenn man nicht gerade nur ein Extrakt der Groesse Luxenburgs verarbeitet, wuerde ich generell die --slim option empfehlen. Wenn man die Daten per diff aktualisieren will, benoetigt man diese Option ohnehin. Und wenn man das nicht will, wuerde ich die Optionen "--slim --drop" vorschlagen.

amm · 2014-05-13 17:28:02

wambacher wrote:

füge noch diese Option hinzu: --flat-nodes ... mit beliebigen Filenamen. Dann legt osm2pgsql die Nodes nicht in der DB ab und performiert erheblich besser.
Achtung: Das File ist wichtig und wird später bei jedem Update der DB gebraucht. Nicht löschen! Beim Full-Planet ist das Teil 22 GB groß, Europa dürfte "etwas" kleiner sein. ~10 GB?

Die Datei ist immer gleich gross, unabhaengig was man importiert. Das heist selbst wenn man nur Luxenburg importiert wird sie mindestens 21GB gross sein. Die Groesse berechnet sich aus der hoechsten node ID * 8 Byte. Derzeit ist die hoechste NodeID bei ca. 2855851760, was eben 21788MB ergibt.

Flat-nodes berechnet die Position in der Datei einer Node anhand ihrer NodeID. Damit spart man sich jedwedige indexierung in der Datei und kann ein lookup in O(1) durchfuehren. Allerdings basiert das darauf das fast alle node ids auch tatsaechlich benoetigt werden. Im full planet sind ca 80% der node ids auch aktuell gueltige nodes. Bei kleinen extrakten wird --flat-nodes hingegen extrem ineffizient (und langsam) und ist somit nur bei full planet imports, bzw sehr grossen Extrakten zu empfehlen, dort wiederum ist es deutlich besser. Ab wann sich --flat-nodes genau lohnt weis ich nicht, aber europa.osm.pbf duerfte wohl von der groesse her in etwa an der Grenze liegen. Da nehmen sich die beiden Optionen wahrscheinlich dann nicht uebermaessig viel.

wambacher · 2014-05-13 18:26:29

SimonPoole wrote:

PS: 5 Tage ist deutlich zu lang,

Kann auch 3 Tage gewesen sein aber mit allen Drum und Dran hat das mehrere Tage gedauert. Hatte auch noch keine SSD.
Dann auch noch den ganzen Hstore mit drin und einige wichtige Indices - wollte halt nur nicht die Erwartungen zu hoch schrauben.

wambacher · 2014-05-13 18:35:09

amm wrote:

wambacher wrote:
Beim Full-Planet ist das Teil 22 GB groß, Europa dürfte "etwas" kleiner sein. ~10 GB?
Die Datei ist immer gleich gross, unabhaengig was man importiert. Das heist selbst wenn man nur Luxenburg importiert wird sie mindestens 21GB gross sein. Die Groesse berechnet sich aus der hoechsten node ID * 8 Byte. Derzeit ist die hoechste NodeID bei ca. 2855851760, was eben 21788MB ergibt.

Wo du recht hast, hast du recht: Für alle Imports gleich, derzeit

 
ls -la /data5/osm/db/planet2/nodes.flat
-rw------- 1 walter walter 22845317128 Mai 13 18:38 /data5/osm/db/planet2/nodes.flat
ls -lah /data5/osm/db/planet2/*
-rw------- 1 walter walter 22G Mai 13 18:38 /data5/osm/db/planet2/nodes.flat

und das mit dem Slim hab ich auch übersehen.

Gruss
walter

berlingo69 · 2014-05-15 07:03:35

Kurze Rückmeldung und vielen Dank an @amm, @Theodin und @SimonPoole das Ihr euch beteiligt.

Etwas Hintergrundwissen, in dem Bezug auf die Einrichtung der Hardwareleistungsmerkmale der VM habe ich nur ein eingeschränkenten Zugriff.
Mir stehen zur Zeit 16 GB RAM und 6 GB SWAP zur Verfügung, ggf. erweitere ich über ein SWAP File.

...

Kommen wir zum jetzigen Stand:

Start gestern in der Früh (bei dem Stand "Relation (42000 ...)" bin ich gestern in froher Erwartung in den den Feierabend gegangen):

osm2pgsql --flat-nodes /osm/planet/europe-altest.flat -r pbf --slim -C 10000 --number-processes 4 /osm/planet/europe-latest.osm.pbf

Für mich zum besseren Verständnis unterteile ich die Verarbeitung von osm2pgsql in zwei (scheinbare) Phasen, die erste Phase endet mit der Auflistung/Statistik von Node/Way/Relation.
Bis dahin hat der Prozess das komplette RAM (16GB) und etwas SWAP verschlungen, soweit so gut...

Heute Morgen sah ich dann das Ergebnis ...

Processing: Node(1205159k 1087.7k/s) Way(148459k 7.98k/s) Relation(1840780 43.93/s)  parse time: 61615s

Node stats: total(1205159819), max(2840683400) in 1108s
Way stats: total(148459463), max(279890005) in 18601s
Relation stats: total(1840788), max(3722607) in 41906s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Plus ...

Going over pending ways...
Maximum node in persistent node cache: 2841640959
        108569071 ways are pending

Using 4 helper-processes
WARNING: Failed to fork helper process 1: Cannot allocate memory. Trying to recover.
WARNING: Failed to fork helper process 2: Cannot allocate memory. Trying to recover.
WARNING: Failed to fork helper process 3: Cannot allocate memory. Trying to recover.
Mid: loading persistent node cache from /osm/planet/europe-altest.flat
Maximum node in persistent node cache: 2841640959
Helper process 0 out of 1 initialised
processing way (27085k) at 1.28k/s (done 0 of 1)

Dann in der zweiten Phase hat der Prozess, weiteren Swap Speicher angefordert und fiel dabei irgendwann auf die Nase, zur Zeit leigt der SWAP bei 2558 von 5117 MB.
Anscheint beginnt er erneut mit der Weg- und Relationsberechnung und wird mir Sicherheit wieder beim Schreiben in die die Datenbank (?) abbrechen?!
Gibt es irgenwo eine tiefergreifende Erläuterung zu dem Verarbeitungsablauf von osm2pgsql?

Ich sehe es schon kommen, das ich bei meinem VMWare Admin weitere 16 GB und mehr SWAP (HD-) Speicher erflehen muss.
Selbstverständlich muss ich den SWAP dann auch noch einrichten, "back to the roots" kann ich da nur sagen...super!

Edit: unwichtiges rausgenommen, Text etwas klarer,11:03 15.05.2014

Last edited by berlingo69 (2014-05-15 10:18:06)

wambacher · 2014-05-15 09:37:46

berlingo69 wrote:

Gibt es irgenwo eine tiefergreifende Erläuterung zu dem Verarbeitungsablauf von osm2pgsql?

außer source-code nicht viel.

Ich sehe es schon kommen, das ich bei meinem VMWare Admin weitere 16 GB und mehr SWAP (HD-) Speicher erflehen muss.
Selbstverständlich muss ich den SWAP dann auch noch einrichten, "back to the roots" kann ich da nur sagen...super!

laß es. dreh den Cache auf 2000 runter, der wird bei --flat-nodes eh nicht gebraucht.

soweit mir langsam dämmert, legt er ohne flat-nodes alle Nodes im Memory-Cache ab - und das sind bei Europa (*) oder gar Full Planet verdammt viele. Dazu kommt wohl ein Design-Bug, daß die Helper genau soviel Memory bekommen sollen, obwohl sie den garnicht benötigen (?). Da nun alle Helper-Prozesse ebenfalls vollen Zugriff auf alle im Memory-Cache stehenden Nodes brauchen, wird bei deren Start eine Memory-Kopie gemacht - und dann knallt es halt.

Es ist wohl so: Kleiner Import (maximal ein Land) ohne --flat-nodes und mit ausreichend Cache / großer Import mit --flat-nodes und kleinem Cache.

gruss
walter

*) Europa alleine machte 2013 ca 50% vom Planeten aus.

EDIT: Cache und Helper überdacht.

Last edited by wambacher (2014-05-15 09:49:38)

SimonPoole · 2014-05-15 09:47:03

wambacher wrote:

... der wird bei --flat-nodes eh nicht gebraucht.

Ausser der Code hat sich sehr geändert in letzter Zeit stimmt das nicht. Die Idee hinter den node cache im File war, a) weniger Platzverbrauch (braucht die DB Tabellen nicht mehr) b) schnelleren Zugriff beim Updaten.

Last edited by SimonPoole (2014-05-15 09:47:44)

wambacher · 2014-05-15 10:01:08

SimonPoole wrote:

wambacher wrote:
... der wird bei --flat-nodes eh nicht gebraucht.
Ausser der Code hat sich sehr geändert in letzter Zeit stimmt das nicht.

Da ich nicht genau verstanden habe, was du hiermit meinst: "hat sich geändert" oder "hat sich nicht geändert"?,
hab ich mal einen Schnellcheck gemacht. Es wird tatsächlich noch an osm2pgsql rumgeschraubt, allerdings beschränkt sich das meines Erachtens auf Kosmetik und Bug-Fixes. Wesentliche Umbauten konnte ich auf die Schnelle nicht erkennen.

https://github.com/openstreetmap/osm2pgsql

daher dürfte das Verhalten ähnlich sein.

Gruss
walter

Last edited by wambacher (2014-05-15 10:02:15)

SimonPoole · 2014-05-15 10:39:20

wambacher wrote:

SimonPoole wrote:
wambacher wrote:
... der wird bei --flat-nodes eh nicht gebraucht.
Ausser der Code hat sich sehr geändert in letzter Zeit stimmt das nicht.
Da ich nicht genau verstanden habe, was du hiermit meinst: "hat sich geändert" oder "hat sich nicht geändert"?,

"hat sich nicht geändert" -> das File wird parallel gefüllt aber nicht anstatt des in-memory caches verwendet.

"hat sich geändert" -> das File wird anstatt des in-memory caches verwendet (was natürlich arsch langsam wäre)

SimonPoole · 2014-05-15 10:52:45

berlingo69 wrote:

....
Für mich zum besseren Verständnis unterteile ich die Verarbeitung von osm2pgsql in zwei (scheinbare) Phasen, die erste Phase endet mit der Auflistung/Statistik von Node/Way/Relation.
Bis dahin hat der Prozess das komplette RAM (16GB) und etwas SWAP verschlungen, soweit so gut...
Heute Morgen sah ich dann das Ergebnis ...
..........
Using 4 helper-processes
WARNING: Failed to fork helper process 1: Cannot allocate memory. Trying to recover.
WARNING: Failed to fork helper process 2: Cannot allocate memory. Trying to recover.
WARNING: Failed to fork helper process 3: Cannot allocate memory. Trying to recover.
Mid: loading persistent node cache from /osm/planet/europe-altest.flat
Maximum node in persistent node cache: 2841640959
Helper process 0 out of 1 initialised
processing way (27085k) at 1.28k/s (done 0 of 1)
.......

Erlaubst du overcommit auf deinem System? Falls nicht dürfte dein Process zu gross zum Forken sein.

Random stackoverflow Artikel dazu http://stackoverflow.com/questions/1560 … mory-error

berlingo69 · 2014-05-15 12:02:28

SimonPoole wrote:

Erlaubst du overcommit auf deinem System? Falls nicht dürfte dein Process zu gross zum Forken sein.
Random stackoverflow Artikel dazu http://stackoverflow.com/questions/1560 … mory-error

Nein, /proc/sys/vm/overcommit_memory steht auf "0". Erhlich gesagt, müsste ich dessen Bedeutung ersteinmal hinterlesen und verstehen

Interessant ist aber, das ich in diesem Bereich ähnlich interveniert habe. Ich habe ein SWAP File angelegt und zur Verfügung gestellt.
Die SWAP Größe liegt nun bei 21117 MB, ich kann nur hoffen, das die restliche Festplattenkapaziät ausreicht.
Das Datenlaufwerk hat ein Kapazität von 256G, europe-latest.osm.pbf sind 13 GB, die dazugehörige flat Datei hat 22 GB (wächst die noch?).
Abzüglich der SWAP Datei mit 16 GB stehen mir aktuell 170 GB zur Verfügung.

Ich habe den Prozess erneut gestartet, mit leichter Veränderung in dem Bezug auf "number-processes", -c ist so geblieben.
Mit weniger Cache geht die Geschwindigkeit drastisch nach unten, wenn ich mich recht erinnere.

 osm2pgsql --flat-nodes /osm/planet/europe-altest.flat -r pbf --slim -C 20000 --number-processes 16 /osm/planet/europe-latest.osm.pbf

Geschwindigkeit aktuell:

Processing: Node(1205159k 1073.2k/s) Way(60713k 26.68k/s) Relation(0 0.00/s)

Speicherverbrauch: 12795 / 16048 MB , Swap 239/21117 MB, Festplatte: /dev/mapper/data-daten 256G 79G 165G 33% /osm

Mal sehen wie es in 3 Stunden aussieht.

wambacher · 2014-05-15 15:18:17

berlingo69 wrote:

Interessant ist aber, das ich in diesem Bereich ähnlich interveniert habe. Ich habe ein SWAP File angelegt und zur Verfügung gestellt.
Die SWAP Größe liegt nun bei 21117 MB, ich kann nur hoffen, das die restliche Festplattenkapaziät ausreicht.
Das Datenlaufwerk hat ein Kapazität von 256G, europe-latest.osm.pbf sind 13 GB, die dazugehörige flat Datei hat 22 GB (wächst die noch?).
Abzüglich der SWAP Datei mit 16 GB stehen mir aktuell 170 GB zur Verfügung

a) full planet braucht ca 500 GB, europa ca 50%, das wird eng.
b) immer noch einen viel zu großen Cache - naja, dein Vergnügen
c) flat=22G ist derzeit aktuelle Größe, wächst mit ca 1GB/Quartal

gruss
walter

im Übrigen würde ich die Anzahl der Helper-Prozesse auf maximal Cores-1 setzen. cores-1 x helper und 1x Postgres-Server, der hat nämlich auch was zu tun.

Last edited by wambacher (2014-05-15 15:22:31)

Announcement

#1 2014-05-12 13:54:03

SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#2 2014-05-12 14:02:07

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#3 2014-05-13 06:37:27

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#4 2014-05-13 07:22:19

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#5 2014-05-13 08:15:40

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#6 2014-05-13 08:17:35

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#7 2014-05-13 08:34:26

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#8 2014-05-13 08:42:09

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#9 2014-05-13 09:12:14

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#10 2014-05-13 12:06:05

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#11 2014-05-13 12:26:17

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#12 2014-05-13 16:34:18

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#13 2014-05-13 16:48:42

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#14 2014-05-13 17:15:43

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#15 2014-05-13 17:28:02

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#16 2014-05-13 18:26:29

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#17 2014-05-13 18:35:09

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#18 2014-05-15 07:03:35

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#19 2014-05-15 09:37:46

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#20 2014-05-15 09:47:03

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#21 2014-05-15 10:01:08

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#22 2014-05-15 10:39:20

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#23 2014-05-15 10:52:45

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#24 2014-05-15 12:02:28

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

#25 2014-05-15 15:18:17

Re: SWITCH2OSM-> eig. Server -> Fehler -> Assertion 'shellCount <= 1'

Board footer