You are not logged in.

Announcement

*** NOTICE: forum.openstreetmap.org is being retired. Please request a category for your community in the new ones as soon as possible using this process, which will allow you to propose your community moderators.
Please create new topics on the new site at community.openstreetmap.org. We expect the migration of data will take a few weeks, you can follow its progress here.***

Pages: 1 2

#26 2014-05-15 15:24:10

berlingo69
Member
Registered: 2014-05-12
Posts: 12

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

Zwischenstand...

Reading in file: /osm/planet/europe-latest.osm.pbf
Processing: Node(1205159k 1073.2k/s) Way(148459k 29.93k/s) Relation(426860 45.82/s)

Speicherverbrauch: 13898 / 16048 MB , Swap 937/21117 MB, Festplatte: /dev/mapper/data-daten  256G     105G  139G   43% /osm

So das sieht doch recht gut aus, nächster Zwischenstand, morgen in der Früh.

Offline

#27 2014-05-15 15:47:33

berlingo69
Member
Registered: 2014-05-12
Posts: 12

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

wambacher wrote:

a) full planet braucht ca 500 GB, europa ca 50%, das wird eng.

Grummel, ich habe mir das fast schon gedacht...

wambacher wrote:

b) immer noch einen viel zu großen Cache  - naja, dein Vergnügen

Ich muss die ersten Erfahrung beim Aufsetzten eine Servers zu sammeln, das (leider) auch noch etwas unter Zeitdruck und "so nebenbei".
Dein Hinweis auf den Cache habe ich wahrgenommen, ich könnte die "technische Seite" noch nicht ganz so erfassen, ich werde das Ganze später nochmal nachlesen.

wambacher wrote:

c) flat=22G ist derzeit aktuelle Größe, wächst mit ca  1GB/Quartal
...
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.

Die "flat-Datei" und das regelmäßig Aktuallisieren ist ein weiteres Thema für später, wie auch die "Helper-Prozesse"(?!)....

Ganz großen Dank Walter...

Last edited by berlingo69 (2014-05-15 15:50:30)

Offline

#28 2014-05-15 17:39:40

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,769
Website

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

berlingo69 wrote:

Zwischenstand...

Reading in file: /osm/planet/europe-latest.osm.pbf
Processing: Node(1205159k 1073.2k/s) Way(148459k 29.93k/s) Relation(426860 45.82/s)

Speicherverbrauch: 13898 / 16048 MB , Swap 937/21117 MB, Festplatte: /dev/mapper/data-daten  256G     105G  139G   43% /osm

So das sieht doch recht gut aus, nächster Zwischenstand, morgen in der Früh.

Leider gibst du den aktuellen Aufruf von osm2pgsql nicht an. Wenn es der gleiche wie von 13:02 ist, bin und bleibe weiterhin pessimistisch.

Du hast zwar den Speicher erhöht, aber den Cache verdoppelt (10 GB->20 GB) und die Anzahl der Helper-Prozesse ebenfalls verdoppelt (8 -> 16). Das müsste in einigen Stunden fürchterlich knallen - oder hast du den von Simon erwähnten Flag /proc/sys/vm/overcommit_memory im Kernel gesetzt? Das könnte was bringen.

warten wir mal ab.

Nachtrag: Warum ziehst du die Sache nicht einfach mit Liechtenstein oder Bremen durch? Dann bekommst du ein Gefühl dafür, was wo abgeht.

Last edited by wambacher (2014-05-15 18:57:41)

Osm Software Watchlist  Osm Emergency Map
Osm Healthcare Map

Offline

#29 2014-05-16 07:56:09

berlingo69
Member
Registered: 2014-05-12
Posts: 12

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

Hallo Walter,

wambacher wrote:

Leider gibst du den aktuellen Aufruf von osm2pgsql nicht an. Wenn es der gleiche wie von 13:02 ist, bin und bleibe weiterhin pessimistisch.

es war der gleiche Aufruf, das Flag von Simon war nicht gesetzt (möchte ersteinmal verstehen was dahinter steckt...).

Den Pessimismus wurde heute morgen bestätigt:

Using 16 helper-processes
WARNING: Failed to fork helper process 1: Cannot allocate memory. Trying to recover.
...
WARNING: Failed to fork helper process 15: 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 (49997k) at 1.42k/s (done 0 of 1)
wambacher wrote:

Nachtrag: Warum ziehst du die Sache nicht einfach mit Liechtenstein oder Bremen durch? Dann bekommst du ein Gefühl dafür, was wo abgeht.

Du hast natülich recht, für ein ersten Testlauf wäre das wohl besser gewesen. Aber aus den erziehlten Ergebnissen (Geschwindigkeit, Verbrauch) kann man schlecht hochrechnen.
Aus diesem Grunde versuche ich auch Europa im gesamten zu importieren, schlussendlich ist dieses auch das Gebiet was ich brauche.

Im Netz habe ich keine "aktuellen" Eckdaten gefunden, es wird immer von "Planet" gesprochen und das wie gesagt auch nicht vom aktuellen Stand.
Ich denke zwei (identische) VMs mit den folgenden Eckdaten, sollten ersteinmal ausreichen: 16 GB Arbeitsspeicher und SWAP, Festplatte System 10-15 GB und für OSM 500 GB.

Ich werde dein Rat beherzigen und ersteinmal Hamburg importieren.

Last edited by berlingo69 (2014-05-16 08:12:12)

Offline

#30 2014-05-16 08:21:09

wambacher
Member
From: Schlangenbad/Wambach, Germany
Registered: 2009-12-16
Posts: 16,769
Website

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

berlingo69 wrote:
wambacher wrote:

Nachtrag: Warum ziehst du die Sache nicht einfach mit Liechtenstein oder Bremen durch? Dann bekommst du ein Gefühl dafür, was wo abgeht.

Du hast natülich recht, für ein ersten Testlauf wäre das wohl besser gewesen. Aber aus den erzielten Ergebnissen (Geschwindigkeit, Verbrauch) kann man schlecht hochrechnen.
Aus diesem Grunde versuche ich auch Europa im gesamten zu importieren, schlussendlich ist dieses auch das Gebiet was ich brauche.

So siehst du wenigstens, ob der Script bis zum Ende durchläuft. Ich schmeiß den "mal eben" für Bremen bei mir an und geb dir Bescheid.

Ich denke zwei (identische) VMs mit den folgenden Eckdaten, sollten ersteinmal ausreichen: 16 GB Arbeitsspeicher und SWAP, Festplatte System 10-15 GB und für OSM 500 GB.

ZWEI? Bring doch erstmal den einen zum laufen. Wenn du den zweiten für Nominatim einsetzen willst, sind die Rahmenbedingungen total verschieden, da osm2pgsql völlig anders vorgeht und die DB auch total anders wird. Allerdings hab ich damit keinerlei praktische Erfahrungen.

Ich werde dein Rat beherzigen und begebe mich auf die Suche, wie ich nur ein Teil der Daten importieren kann.

Einfach das Datenfile durch einen kleinere Version ersetzen. Bei der Geofabrik gíbt es doch genug Auswahl.

Vorsicht: da das Test-Datenfile erheblich kleiner sein sollte als Europa, würden die für kleine Files vorgesehene Einstellungen (großer Cache, keine Helper-Prozesse und kein Flat-File) prima funktionieren. Aber das ist ja nicht Sinn der Sache.

Und bitte glaub mir: du brauchst viel Memory, aber keinen großen Cache. Der Memory sollte Postgresql zugewiesen werden - aber erst nach dem Import, sonst verzettelst du dich noch.

Gruss

walter

Feddich:

walter@wno-server:/data/walter/osm/db/bremen$ ./init_db_pbf 
++ /opt/install/osm/osm2pgsql/osm2pgsql --verbose -c --slim --style ../wno.style -d bremen -l -U postgres --hstore-all --number-processes 7 -C 1000 --keep-coastlines -G --flat-nodes bremen.nodes /data4/import/tmp/bremen-latest.osm.pbf
osm2pgsql SVN version 0.83.0 (64bit id space)

Using projection SRS 4326 (Latlong)
Setting up table: planet_osm_point
NOTICE:  table "planet_osm_point" does not exist, skipping
NOTICE:  table "planet_osm_point_tmp" does not exist, skipping
Setting up table: planet_osm_line
NOTICE:  table "planet_osm_line" does not exist, skipping
NOTICE:  table "planet_osm_line_tmp" does not exist, skipping
Setting up table: planet_osm_polygon
NOTICE:  table "planet_osm_polygon" does not exist, skipping
NOTICE:  table "planet_osm_polygon_tmp" does not exist, skipping
Setting up table: planet_osm_roads
NOTICE:  table "planet_osm_roads" does not exist, skipping
NOTICE:  table "planet_osm_roads_tmp" does not exist, skipping
Using built-in tag processing pipeline
Allocating memory for dense node cache
Allocating dense node cache in one big chunk
Allocating memory for sparse node cache
Sharing dense sparse
Node-cache: cache=1000MB, maxblocks=128000*8192, allocation method=11
Mid: loading persistent node cache from bremen.nodes
Allocated space for persistent node cache file
Maximum node in persistent node cache: 0
Mid: pgsql, scale=10000000 cache=1000
Setting up table: planet_osm_nodes
NOTICE:  table "planet_osm_nodes" does not exist, skipping
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_nodes_pkey" for table "planet_osm_nodes"
Setting up table: planet_osm_ways
NOTICE:  table "planet_osm_ways" does not exist, skipping
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_ways_pkey" for table "planet_osm_ways"
Setting up table: planet_osm_rels
NOTICE:  table "planet_osm_rels" does not exist, skipping
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "planet_osm_rels_pkey" for table "planet_osm_rels"

Reading in file: /data4/import/tmp/bremen-latest.osm.pbf
Processing: Node(889k 3.8k/s) Way(167k 33.41k/s) Relation(3840 16.27/s)  parse time: 477s

Node stats: total(889536), max(2860573546) in 236s
Way stats: total(167071), max(282119965) in 5s
Relation stats: total(3842), max(3746138) in 236s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Going over pending ways...
Maximum node in persistent node cache: 2861563903
	115874 ways are pending

Using 7 helper-processes
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Helper process 5 out of 7 initialised          
Helper process 4 out of 7 initialised          
Helper process 0 out of 7 initialised          
Helper process 3 out of 7 initialised          
Helper process 1 out of 7 initialised          
Helper process 2 out of 7 initialised          
Helper process 6 out of 7 initialised          
Process 4 finished processing 16553 ways in 7 sec
processing way (104k) at 14.94k/s (done 1 of 7)Maximum node in persistent node cache: 2861563903
Process 5 finished processing 16553 ways in 7 sec
Maximum node in persistent node cache: 2861563903
Process 0 finished processing 16554 ways in 7 sec
Process 2 finished processing 16554 ways in 7 sec
Maximum node in persistent node cache: 2861563903
Process 6 finished processing 16553 ways in 8 sec
Maximum node in persistent node cache: 2861563903
Process 1 finished processing 16554 ways in 8 sec
Maximum node in persistent node cache: 2861563903
Process 3 finished processing 16553 ways in 8 sec
Maximum node in persistent node cache: 2861563903

All child processes exited

115874 Pending ways took 8s at a rate of 14484.25/s
Committing transaction for planet_osm_point
Committing transaction for planet_osm_line
Committing transaction for planet_osm_polygon
Committing transaction for planet_osm_roads

Going over pending relations...
Maximum node in persistent node cache: 2861563903
	0 relations are pending

Using 7 helper-processes
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Mid: loading persistent node cache from bremen.nodes
Maximum node in persistent node cache: 2861563903
Process 3 finished processing 0 relations in 1 sec
Maximum node in persistent node cache: 2861563903
Process 0 finished processing 0 relations in 2 sec
Process 1 finished processing 0 relations in 2 sec
Maximum node in persistent node cache: 2861563903
Process 2 finished processing 0 relations in 2 sec
Process 4 finished processing 0 relations in 2 sec
Process 6 finished processing 0 relations in 2 sec
Process 5 finished processing 0 relations in 2 sec
Maximum node in persistent node cache: 2861563903
Maximum node in persistent node cache: 2861563903
Maximum node in persistent node cache: 2861563903
Maximum node in persistent node cache: 2861563903

All child processes exited
0 Pending relations took 2s at a rate of 0.00/s

Sorting data and creating indexes for planet_osm_line
Sorting data and creating indexes for planet_osm_polygon
Sorting data and creating indexes for planet_osm_point
node cache: stored: 889536(100.00%), storage efficiency: 51.32% (dense blocks: 147, sparse nodes: 791447), hit rate: 100.00%
Sorting data and creating indexes for planet_osm_roads
Maximum node in persistent node cache: 2861563903
Stopping table: planet_osm_nodes
Stopping table: planet_osm_rels
Stopped table: planet_osm_nodes in 0s
Stopping table: planet_osm_ways
Building index on table: planet_osm_rels (fastupdate=off)
Building index on table: planet_osm_ways (fastupdate=off)
Stopped table: planet_osm_rels in 0s
Analyzing planet_osm_roads finished
Analyzing planet_osm_point finished
Analyzing planet_osm_polygon finished
Analyzing planet_osm_line finished
Copying planet_osm_roads to cluster by geometry finished
Creating geometry index on  planet_osm_roads
Creating osm_id index on  planet_osm_roads
Creating indexes on  planet_osm_roads finished
All indexes on  planet_osm_roads created  in 2s
Completed planet_osm_roads
Copying planet_osm_point to cluster by geometry finished
Creating geometry index on  planet_osm_point
Copying planet_osm_line to cluster by geometry finished
Creating geometry index on  planet_osm_line
Creating osm_id index on  planet_osm_point
Creating indexes on  planet_osm_point finished
Copying planet_osm_polygon to cluster by geometry finished
Creating geometry index on  planet_osm_polygon
Creating osm_id index on  planet_osm_line
All indexes on  planet_osm_point created  in 3s
Completed planet_osm_point
Creating indexes on  planet_osm_line finished
All indexes on  planet_osm_line created  in 4s
Completed planet_osm_line
Stopped table: planet_osm_ways in 4s
Creating osm_id index on  planet_osm_polygon
Creating indexes on  planet_osm_polygon finished
All indexes on  planet_osm_polygon created  in 5s
Completed planet_osm_polygon

Osm2pgsql took 495s overall
walter@wno-server:/data/walter/osm/db/bremen$

Last edited by wambacher (2014-05-16 09:01:49)

Osm Software Watchlist  Osm Emergency Map
Osm Healthcare Map

Offline

#31 2014-05-19 06:35:05

berlingo69
Member
Registered: 2014-05-12
Posts: 12

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

@wambacher@all,
Hallo Walter,

der Import von Hamburg hat einwandfrei funktioniert, der "Fehler -> Assertion 'shellCount <= 1'" tauchte nicht mehr auf.
Ich denke die Aktuallsierung auf 3.3.3 war der richtige Schritt.

Ich wurde nun wieder abkommandieren, ich werde von nun an (wieder) die Entwicklungsarbeiten unterstützen (AngularJS), Verschiebung der Prioritäten.
Ein Kollegen wird "by the way" den Server nach und nach aufsetzen, ich werde Ihn dann später wieder zu Gesicht bekommen smile

Vielen dank an alle für die Unterstüzung, ist schon schade das ich hier nicht weiter machen kann.

Gruß
Erik

Offline

#32 2014-05-19 19:37:56

amm
Member
Registered: 2009-09-20
Posts: 618
Website

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

berlingo69 wrote:
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 neutral

Das Problem liegt wie folgt. In der ersten Phase belaedt osm2pgsql den in-memory node cache, welcher bei einem full-planet bis zu ca. 22GB gross sein kann. In der "going over pending ways" phase, erstellt osm2pgsql mehrere "Helper prozesse" um moderne multi-core CPUs besser auszunuetzen. Bei einem Fork wird der ganze Speicher im Prinzip in jedem Prozess dupliziert. Wenn man also --number-processes 16 einstellt, wird der Prozess 15 mal dupliziert. Bei 22 GB pro Prozess waeren das 352 GB an RAM. Allerdings duplizieren alle modernen Betriebsysteme den Speicher zunaechst einmal nicht wirklich, sondern mappen den virtuell duplizierten Speicher in den gleichen physischen speicher. Erst wenn sich der Speicher in den Prozessen unterscheidet wird tatsaechlich mehr physischer Speicher benoetigt (Copy-on-write). Da osm2pgsql den node Speicher nicht mehr veraendert, werden diese 22GB also nie wirklich kopiert und der tatsaechlich benoetigte physischer Speicher ueberschreitet die 22GB nicht. Allerdings weis das Betriebsystem das nicht, sonder sieht nur das es eine moeglichkeit gibt das am Ende die 352GB benoetigt werden und lehnt das Forken mit out of memory moeglicherweise ab. Und das ist wo das over commit hilft, denn es sagt, das das Betriebsystem dann erst mit OOM Fehlern abbricht wenn tatsaechlich nicht mehr genuegend Arbeitsspeicher vorhanden ist und nicht schon wenn zu viel angefragt wurde.

Besser waere wenn osm2pgsql direkt shared memory verwenden wuerde und nicht auf copy-on-write und overcommit angewiesen ist, aber ich bin bislang noch nie dazu gekommen dies zu korrigieren.

Offline

Pages: 1 2

Board footer

Powered by FluxBB