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

Ven 22 Mai 16:36:34 UTC 2015

Il a peut être manqué la phase finale d'optimisation et de reclustering des
données.

Le 21 mai 2015 22:05, Vincent Frison <vincent.frison at gmail.com> a écrit :

> Hier soir au bout d'environ 48h ça n'était toujours pas fini mais c'était
> sans doute pas très loin puisqu'il avait visiblement fini d'indexer toutes
> les tables. Je suis allé me coucher mais pas de bol il y a eu une coupure
> de courant durant la nuit, décidément...
>
> J'ai quand même l'impression que ça avait bien fini.. au final j'ai une
> base qui pèse 76 Gb et il y a 43 094 761 lignes dans la table
> planet_osm_polygon, si quelqu'un pouvait confirmer...
>
> En tout cas les indexes sur les géométries font bien leur boulot puisque
> les requêtes les utilisant sont aussi rapides que lorsque j'utilisais des
> bases avec une seule région ! :)
>
>
> Le 18 mai 2015 22:48, Vincent Frison <vincent.frison at gmail.com> a écrit :
>
>> Mon dernier essai s'est bloqué au bout de ~1,5j à cause... d'un problème
>> d'espace disque ! :)
>>
>> Bon là je retente sur une autre partition avec plus de 250 GB d'espace
>> libre et avec cette option flat-nodes qui a l'air sympathique
>> effectivement. Je met également 2 processes et soyons fou 2 Gb de cache car
>> avec un seul GB et un seul process c'était un peu trop pépére même pour mon
>> vieux laptop (seulement 1/4 du CPU et 2,8 Gb utilisé par osm2pgsql)
>>
>> Le 18 mai 2015 09:30, Christian Quest <cquest at openstreetmap.fr> a écrit :
>>
>>> --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
>>>
>>> _______________________________________________
>>> dev-fr mailing list
>>> dev-fr at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/dev-fr
>>>
>>>
>>
>
> _______________________________________________
> 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/20150522/9e6194f2/attachment.html>