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
“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)
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/15608347/fork-failing-with-out-of-memory-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.
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.
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.
Grummel, ich habe mir das fast schon gedacht…
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.
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…
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.
Hallo Walter,
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)
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.
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.
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.
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$
@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 
Vielen dank an alle für die Unterstüzung, ist schon schade das ich hier nicht weiter machen kann.
Gruß
Erik
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.