Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
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.fri...@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 cqu...@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) lis...@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 cœur 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) lis...@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.fri...@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@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=64*8192,
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
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 cqu...@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) lis...@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 cœur 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) lis...@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.fri...@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@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=64*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
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
--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) lis...@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) lis...@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.fri...@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@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=64*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 à
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
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 cœur 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) lis...@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.fri...@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@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=64*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 -- sly ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr -- sly (sylvain letuffe)
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
Merci pour vos retours.. Sly pourquoi ne mettre qu'un seul processs ? Je crois que mon processeur est un double cœur 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) lis...@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.fri...@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@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=64*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 -- sly ___ 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
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
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=64*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
Re: [OSM-dev-fr] Chargement de toute la France dans PostGIS
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.fri...@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@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=64*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 -- sly ___ dev-fr mailing list dev-fr@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev-fr
