j'ai exactement eu ce genre de soucis, j'ai resolu de façon empirique ne
connaissant pas le sujet.

comme "ca marchait pas", j'ai essayé avec l'extract de la corse
(tout petit ca devait marcher...) en mode slim sans number-processes

j'ai corrigé suivant les msg erreur par recherche internet
http://wiki.openstreetmap.org/wiki/Osm2pgsql#Optimization
http://wiki.openstreetmap.org/wiki/PostgreSQL#Tune_the_database
... et d'autres dont je n'ai pas gardé de liens

2 eme etape, controle de l'utilisation des ressources avec le moniteur
systeme (memoire, swap et taille disque utilisé) et du log postgresql

modification des parametres postgresql pour "voir" ce que ca fait et si
cela utilise plus ou moins de ressources.

ca a ete laborieux....

Le vendredi 15 mai 2015 à 23:50 +0200, Vincent Frison 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
> dev-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/dev-fr



_______________________________________________
dev-fr mailing list
dev-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/dev-fr

Répondre à