Optimisation des importations osm2pgsql pour les données OSM

27

Je construis actuellement une instance sur EC2 sur laquelle importer l'intégralité de l'instantané Planet.osm de la valeur de la Terre entière pour certains projets sur lesquels nous travaillons. J'ai créé une grande instance Ubuntu x64 et attaché beaucoup de stockage séparé sur un volume EBS pour la base de données Postgres et l'ai modifié pour y héberger les données PGSQL.

Maintenant, le serveur a du mal à utiliser osm2pgsqlpour importer l'instantané ... Après quelques tentatives avec différentes configurations de mémoire et ainsi de suite, le processus continue de produire "Killed" après avoir parcouru presque tout le chemin; une fois qu'il a été tué en "parcourant les voies en attente" et la prochaine fois, après avoir légèrement ajusté le cache mince, il a atteint les "voies de traitement" avant de s'écraser. D'après ce que j'ai lu, cela est généralement dû à des problèmes de mémoire.

Voici ma dernière tentative d'exécuter l'importation:

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

Et voici les spécifications d'une grande instance sur EC2:

Grande instance 7,5 Go de mémoire, 4 unités de calcul EC2 (2 cœurs virtuels avec 2 unités de calcul EC2 chacune), 850 Go de stockage d'instance locale, plate-forme 64 bits

Ma question est - existe-t-il de bonnes ressources de référence pour déterminer les exigences de réglage pour osm2pgsql et Postgres? Vitesse d'importation est même pas important pour moi, je voudrais simplement être en mesure de vous assurer que le processus se termine en toute sécurité, même si cela prend 4 ou 5 jours ... Je l' ai lu "de Frederick Ramm Optimisation du rendu chaîne "(PDF) du SOTM de l'an dernier, mais existe-t-il d'autres bonnes opinions / ressources?

— colemanm
source

Ne serait-ce pas très cher de faire ça sur EC2?

— Pablo

Il n'est pas bon marché de le faire fonctionner, mais le plan provisoire consiste à le faire tourner, à générer un jeu de tuiles, puis à le fermer et à utiliser cet ensemble pendant un certain temps jusqu'à ce que nous ayons besoin d'appliquer des mises à jour. C'est toujours beaucoup moins cher que d'acheter un serveur massif ...

— colemanm

1

Intéressant! Je n'ai jamais essayé cela sur mon ancienne XP-Home-Box. Ça marche vraiment? Je demande parce qu'il a été écrit pour convertir des extraits de Geofabrik ou Cloudmade pas pour la planète entière. La planète semble être XML non valide. Comment avez-vous résolu ce problème?

@Carsten En migrant votre réponse à un formulaire de commentaire, j'ai supprimé par inadvertance un commentaire de @jvangeld. Le voici: Salut Carsten, bienvenue sur GIS.se. C'est génial quand les développeurs viennent ici pour aider les gens avec leurs programmes. Mais votre réponse ici aurait probablement été meilleure en tant que commentaire au message de @ winwaed. Encore une fois, je suis ravi de vous avoir ici!

— whuber

8

Comme le dit la documentation, vous aurez peut-être besoin de plus de 256 Go de RAM pour le faire.

Je ne connais pas grand-chose à l'EC2, mais vous pouvez essayer le mode mince (--slim) ou essayer l' osmose .

Il y a un article intéressant: http://weait.com/content/build-your-own-openstreetmap-server Il dit: «vous devez utiliser le mode slim».

— Pablo
source

Ouais, je comprends aussi que le mode slim est requis pour appliquer les diffs aux mises à jour.

— colemanm

4

En raison des contraintes de mémoire, je n'ai même pas essayé d'utiliser osm2pgsql pour charger les données de routage de planet.osm. Au lieu de cela, j'ai utilisé osm2po:

http://osm2po.de/

La plupart de la documentation est en allemand mais avec un peu d'expérimentation, j'ai réussi à la faire fonctionner. Prend quelques jours sur un Core 2 Quad dédié (mais il n'utilise qu'un seul thread).

— winwaed
source

2

Je suis tombé sur ce qui suit en cherchant autre chose http://aws.amazon.com/datasets/2844 - Je ne sais pas si cela vous aidera ou non, mais cela pourrait être un point de départ.

— Ian Turton
source

Cela pourrait certainement fonctionner pour le moment, même si c'est à partir de 2009 ...

— colemanm

2

Avez-vous obtenu une solution à votre problème, autre que l'utilisation d'un ancien package pré-généré? Je semble avoir un problème très similaire dans l'instance EC2. J'utilise pbf planet depuis 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

Mise à jour: il semble que j'ai trouvé une solution - après avoir réduit la mémoire demandée à 6 Go (paramètre -C 6000), le processus fonctionne (au moins a fonctionné pendant plusieurs jours maintenant, se terminera aujourd'hui, je l'espère).

Il semble que l'instance m1.large avec 7,5 Go de mémoire soit légèrement trop petite pour adapter tous les nœuds à la mémoire (ce qui devrait nécessiter environ 11 Go de nos jours). L'osm2pgsql semble nécessiter moins de 700 Mo supplémentaires pour la mémoire requise, donc avec -C 7000 il fonctionne juste à court de mémoire, mais avec -C 6000 (ou peut-être aussi -C 6500) cela fonctionne.

Je suggère également d'utiliser une instance de mémoire supérieure avec au moins 15 Go de RAM, cela devrait rendre l'importation beaucoup plus rapide. Ou même doubler une instance de mémoire extra large qui coûterait le double, mais devrait être capable d'importer la planète entière en mode non mince en moins de 5 heures (environ 3 à 4 fois plus rapide qu'en mode mince). Ce serait donc moins cher.

— JaakL
source

1

J'ai obtenu osm2pgsql pour travailler sur EC2 en utilisant moins de CPU et plus de RAM. Il a échoué en raison de problèmes de mémoire jusqu'à ce que j'augmente l'instance à une mémoire extra-large avec 17 Go de RAM.

— datdo
source