[OSM-dev-fr] Chargement de toute la France dans PostGIS

Lun 18 Mai 07:30:18 UTC 2015

--slim obligatoire pour ne pas être en out of memory
--flat-nodes obligatoires aussi...

Pour descendre le temps d'import, le plus efficace c'est le SSD.

Un peu de tuning postgres peut aider aussi, mais c'est une science occulte !

Voilà un exemple d'import France sur une machine avec 8Go et 4 coeurs (et 1
SSD):
http://wiki.openstreetmap.org/wiki/Osm2pgsql/benchmarks/LS21_Blade_with_SSD

Le 16 mai 2015 16:38, sly (sylvain letuffe) <liste2 at letuffe.org> a écrit :

> Le samedi 16 mai 2015 14:09:01, Vincent Frison a écrit :
> > Merci pour vos retours..
> >
> > Sly pourquoi ne mettre qu'un seul processs ?
>
> J'ignore si c'est toujours le cas, mais il fût un temps, quand on
> choisissait
> multiple processus avec osm2pgsql, il consommait plus de mémoire sur la
> partie
> création des polygones de relation.
> Comme de toute façon, ta ressource limitante sera, de très loin, le disque
> très lent de ton portable (sauf ssd ?). Il faut laisser au maximum
> possible de
> mémoire au kernel linux pour qu'il puisse mettre le plus de chose en cache
> RAM
> possible. Et accessoirement fermer le plus grand nombre d'autres
> applications
> possible.
>
> Mais si tu as le courage, tu peux tenter avec 4 puis 1 processus. Ça nous
> permettra de savoir ce qui est le plus rentable dans un config avec mémoire
> limitée.
>
>
> > Je crois que mon processeur
> > est un double coeur mais concrètement ça en fait 4 (à cause de
> > l'hyperthreading?), en tout je "vois" 4 processeurs en faisant un "cat
> > /proc/cpuinfo".
> >
> > Sinon ok je me suis rajouté 12 GB de swap et je vais refaire une
> tentative
> > cette nuit en mettant la cache à seulement 1GB car effectivement ce
> > paramètre ne concerne que la cache et il faut bien garder un peu de
> mémoire
> > pour le reste...
> >
> > Le 16 mai 2015 13:31, sly (sylvain letuffe) <liste2 at letuffe.org> a
> écrit :
> > > J'importe l'europe sur une machine avec 16go et 4 disques raid rotatifs
> > > en 5jours. Je pense que ca devrait le faire pour ta config sur la
> france
> > > uniquement avec de la patience.
> > >
> > > Pour 8go de ram, ce qui est peu n'active pas autant de cache avec -C
> > > sinon il n'en reste pas assez pour les autres traitements.
> > > Selon moi :
> > > --slim obligé
> > > -C 800
> > > --number-process=1
> > > Et ajoute au moins 4 voir 8go de swap
> > >
> > > Et arme toi de patience. Vu ta config, je tablerais sur 72h voir plus
> > > Sinon, importe sur une autre machine et dump puis restore
> > >
> > > Le 15 mai 2015 23:50:12 CEST, Vincent Frison <vincent.frison at gmail.com>
> a
> > >
> > > écrit :
> > > >Hello,
> > > >
> > > >J'aimerais avoir un peu de retour d'expérience si certains parmi vous
> > > >se
> > > >sont déjà amusé à charger l'ensemble de la France dans une base
> > > >PostGIS.
> > > >
> > > >En sachant que dans mon cas ça serait un vieux laptop avec Corei5 at 2,4
> > > >GHz
> > > >et simplement 8 GB de RAM. Peut-être que je rêve en couleur avec une
> > > >configuration aussi limitée, en tout cas c'est pas grave si ça prend
> > > >plusieurs jours à charger...
> > > >
> > > >J'ai donc essayé de charger le fichier PBF, 3 GB tout de même, mais
> > > >pour
> > > >l'instant c'est un échec.
> > > >
> > > >J'ai d'abord essayé sans l'option --slim mais ça a crashé au bout de
> > > >plus
> > > >de 24h (je n'ai plus le message d'erreur exact malheureusement).
> > > >
> > > >Ma dernière tentative avec plus de cache (osmpgsql -s -c -C 5000
> > > >--number-processes=3) n'a pas vraiment planté mais ça a quand même
> > > >joliment
> > > >foiré puisque je me retrouve qu'avec 160k ways au lieu des 48M
> > > >visiblement
> > > >prévus.
> > > >
> > > >Voici les logs:
> > > >
> > > >Using projection SRS 900913 (Spherical Mercator)
> > > >[...]
> > > >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=5000MB, maxblocks=640000*8192, allocation method=11
> > > >Mid: pgsql, scale=100 cache=5000
> > > >Setting up table: planet_osm_nodes
> > > >
> > > >Reading in file:
> > > >/home/turman/Temporary/GeoData/OSM/france-latest.osm.pbf
> > > >Processing: Node(328394k 132.7k/s) Way(48772k 38.71k/s)
> Relation(382850
> > > >24.75/s)  parse time: 19203s
> > > >
> > > >Node stats: total(328394512), max(3511063881) in 2475s
> > > >Way stats: total(48772758), max(344356113) in 1260s
> > > >Relation stats: total(382854), max(5126005) in 15469s
> > > >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...
> > > >pending_ways failed: out of memory for query result
> > > >(7)
> > > >Error occurred, cleaning up
> > > >
> > > >Au vu du message d'erreur, dois je augmenter la taille du cache ?
> > > >Malheureusement je suis déjà pas très loin de ma limite physique, mais
> > > >je
> > > >pourrais me créer un swap.. swap que je n'ai pas actuellement, d'où
> > > >peut-être mes problèmes d'ailleurs !
> > > >
> > > >Bref si vous avez des conseils ou des bonnes options je suis preneur.
> > > >
> > > >Merci, Vincent.
> > > >
> > > >PS: j'utilisais avant une version bien à jour d'osm2pgsql compilée
> > > >depuis
> > > >Git mais depuis ma mise à jour vers Debian 8 j'ai des soucis de
> > > >compilation, du coup j'utilise la version packagée dans Jessie cad SVN
> > > >version 0.86.0 (64bit id space).
> > > >
> > > >
> > >
> >------------------------------------------------------------------------
> > > >
> > > >_______________________________________________
> > > >dev-fr mailing list
> > > >dev-fr at openstreetmap.org
> > > >https://lists.openstreetmap.org/listinfo/dev-fr
> > >
> > > --
> > > sly
> > >
> > > _______________________________________________
> > > dev-fr mailing list
> > > dev-fr at openstreetmap.org
> > > https://lists.openstreetmap.org/listinfo/dev-fr
>
> --
> sly (sylvain letuffe)
> http://wiki.openstreetmap.org/wiki/User:Sletuffe
>
> _______________________________________________
> dev-fr mailing list
> dev-fr at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr
>

-- 
Christian Quest - OpenStreetMap France
-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://lists.openstreetmap.org/pipermail/dev-fr/attachments/20150518/b3948bdd/attachment.html>