Ottimizzazione delle importazioni di osm2pgsql per i dati OSM

27

Attualmente sto sviluppando un'istanza su EC2 su cui importare l'intera istantanea Planet.osm dei dati dell'intera Terra per alcuni progetti su cui stiamo lavorando. Ho creato una grande istanza di Ubuntu x64 e ho collegato un sacco di spazio di archiviazione separato su un volume EBS per il database Postgres e l'ho modificato per ospitare lì i dati PGSQL.

Ora il server sta riscontrando problemi nell'utilizzare osm2pgsqll'importazione dell'istantanea ... Dopo un paio di tentativi con configurazioni di memoria diverse e quant'altro, il processo continua a produrre "Killed" dopo aver attraversato quasi tutto il percorso; una volta è stato ucciso mentre "esaminava i modi in sospeso" e la volta successiva, dopo aver leggermente modificato la cache sottile, ha raggiunto i "modi di elaborazione" prima di schiantarsi. Da quello che ho letto, questo è generalmente dovuto a problemi di memoria.

Ecco il mio ultimo tentativo di eseguire l'importazione:

osm2pgsql -v -U osm -s -C 4096 -S default.style -d osm /data/osm/planet-latest.osm.bz2

Ed ecco le specifiche per un'istanza di grandi dimensioni su EC2:

Grande istanza 7,5 GB di memoria, 4 unità di calcolo EC2 (2 core virtuali con 2 unità di calcolo EC2 ciascuna), 850 GB di memoria di istanza locale, piattaforma a 64 bit

La mia domanda è: ci sono alcune buone risorse di benchmark per determinare i requisiti di ottimizzazione per osm2pgsql e Postgres? La velocità di importazione non è nemmeno così importante per me, vorrei solo essere in grado di assicurarmi che il processo si completasse in modo sicuro, anche se ci vogliono 4 o 5 giorni ... Ho letto attraverso "L' ottimizzazione del rendering di Frederick Ramm catena "(PDF) documento dal SOTM dell'anno scorso, ma ci sono altre buone opinioni / risorse?

— colemanm
fonte

Non sarebbe molto costoso farlo su EC2?

— Pablo,

Non è economico per mantenerlo in esecuzione, ma il piano intermedio è di ruotarlo, generare un set di tessere, quindi spegnerlo e utilizzare tale set per un po 'fino a quando non è necessario applicare gli aggiornamenti. È ancora molto più economico rispetto all'acquisto di un server enorme ...

— Colemanm,

1

Interessante! Non l'ho mai provato sul mio vecchio XP-Home-Box. Funziona davvero? Lo sto chiedendo perché è stato scritto per convertire estratti da Geofabrik o Cloudmade non per l'intero pianeta. Il pianeta sembra essere XML non valido. Come hai risolto questo problema?

@Carsten Nel migrare la tua risposta a un modulo di commento, ho inavvertitamente eliminato un commento di @jvangeld. Eccolo: Ciao Carsten, benvenuto su GIS.se. È fantastico quando gli sviluppatori vengono qui per aiutare le persone con i loro programmi. Ma la tua risposta qui probabilmente sarebbe stata migliore come commento al post di @ winwaed. Ancora una volta, è bello averti qui!

— whuber

8

Come dice la documentazione, potresti aver bisogno di più di 256 GB di RAM per farlo.

Non so molto su EC2, ma puoi provare la modalità slim (--slim) o provare l' osmosi .

C'è un post interessante: http://weait.com/content/build-your-own-openstreetmap-server Dice "devi usare la modalità slim".

— Pablo
fonte

Sì, capisco anche che per applicare gli aggiornamenti è necessaria la modalità slim.

— Colemanm,

4

A causa dei vincoli di memoria non ho nemmeno provato a usare osm2pgsql per caricare i dati di routing di planet.osm. Invece ho usato osm2po:

http://osm2po.de/

La maggior parte della documentazione è in tedesco, ma con un po 'di sperimentazione sono riuscito a farlo funzionare. Richiede alcuni giorni su un Core 2 Quad dedicato (ma utilizza solo un thread).

— Winwaed
fonte

2

Mi sono imbattuto in quanto segue mentre cercavo qualcos'altro http://aws.amazon.com/datasets/2844 - Non sono sicuro se ti aiuterà o no, ma potrebbe essere un punto di partenza.

— Ian Turton
fonte

Questo potrebbe sicuramente funzionare per ora, anche se è del 2009 ...

— colemanm,

2

Hai trovato una soluzione al tuo problema, oltre all'utilizzo del vecchio pacchetto pre-generato? Mi sembra di avere un problema molto simile nell'istanza EC2. Sto usando il pianeta pbf da http://download.bbbike.org/osm/

time ./osm2pgsql -S default.style --slim -d gis -C 7000 --hstore /mnt/planet/planet-latest.osm.pbf
osm2pgsql SVN version 0.70.5
...(creating db tables)
Reading in file: /mnt/planet/planet-latest.osm.pbf
Processing: Node(741920k) Way(0k) Relation(0)Killed

real    276m47.695s

Aggiornamento: sembra che ho trovato la soluzione - dopo aver ridotto la memoria richiesta a 6 GB (parametro -C 6000) il processo funziona (almeno ha funzionato per diversi giorni ora, finirò oggi spero).

Sembra che l'istanza m1.large con 7,5 GB di memoria sia leggermente troppo piccola per adattare tutti i nodi alla memoria (che dovrebbe richiedere circa 11 GB al giorno d'oggi). Sembra che osm2pgsql richieda meno di 700 MB in più alla memoria richiesta, quindi con -C 7000 ha poca memoria, ma con -C 6000 (o forse anche -C 6500) funziona.

Inoltre suggerirei di utilizzare un'istanza di memoria superiore con almeno 15 GB di RAM, dovrebbe rendere l'importazione molto più veloce. O anche una doppia istanza di memoria extra large che costerebbe il doppio, ma dovrebbe essere in grado di eseguire l'importazione completa del pianeta in modalità non sottile entro <5 ore (circa 3-4 volte più veloce della modalità slim). Quindi sarebbe effettivamente più economico.

— JaakL
fonte

1

Ho osm2pgsql a lavorare su EC2 usando meno CPU e più RAM. Non è riuscito a causa di problemi di memoria fino a quando non ho elevato l'istanza a una memoria molto grande con 17 concerti di ram.

— datdo
fonte