Il a peut être manqué la phase finale d'optimisation et de reclustering des données.
Le 21 mai 2015 22:05, Vincent Frison <[email protected]> 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 <[email protected]> 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 <[email protected]> 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) <[email protected]> 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) <[email protected]> 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 < >>>> [email protected]> 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@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 >>>> > > >[email protected] >>>> > > >https://lists.openstreetmap.org/listinfo/dev-fr >>>> > > >>>> > > -- >>>> > > sly >>>> > > >>>> > > _______________________________________________ >>>> > > dev-fr mailing list >>>> > > [email protected] >>>> > > https://lists.openstreetmap.org/listinfo/dev-fr >>>> >>>> -- >>>> sly (sylvain letuffe) >>>> http://wiki.openstreetmap.org/wiki/User:Sletuffe >>>> >>>> _______________________________________________ >>>> dev-fr mailing list >>>> [email protected] >>>> https://lists.openstreetmap.org/listinfo/dev-fr >>>> >>> >>> >>> >>> -- >>> Christian Quest - OpenStreetMap France >>> >>> _______________________________________________ >>> dev-fr mailing list >>> [email protected] >>> https://lists.openstreetmap.org/listinfo/dev-fr >>> >>> >> > > _______________________________________________ > dev-fr mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/dev-fr > > -- Christian Quest - OpenStreetMap France
_______________________________________________ dev-fr mailing list [email protected] https://lists.openstreetmap.org/listinfo/dev-fr
