Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Probleme d'import des cours d'eau dans georiviere #223

Open
remichairat opened this issue Dec 6, 2023 · 1 comment
Open

Probleme d'import des cours d'eau dans georiviere #223

remichairat opened this issue Dec 6, 2023 · 1 comment
Assignees

Comments

@remichairat
Copy link

Bonjour,

Je rencontre un souci depuis quelques temps pour importer les données cours d'eau dans georiviere en effet après avoir corriger les problème de topologie et d'attribut de ma données sources a savoir la bdtopo de l'IGN en suivant la documentation de geotrek : https://geotrek.readthedocs.io/en/master/install/import.html
je rencontre toujours le même problèmes a savoir que l’exécutions de mon script python fonctionne correctement jusqu'a entre le 180 et 201 éléments ou celui-ci pour une raison encore inconnu ce stop sans message d'erreur le souci étant que j'ai environs 14000 éléments a charger et que l’arrêt ne ce fait pas toujours sur le même éléments mais plutôt de façon aléatoire, il est egalement important de noté que les éléments que je reussi a pousser sont bien chargé sur le postgres.
je vous joints le script python que j’exécute pour envoyer les données sur postgres.

Cordialement,

Rémi
commande_pousser_bdtopage.py.txt
cour_eau.zip

@babastienne
Copy link
Member

babastienne commented Dec 9, 2023

J'ai pris un peu de temps aujourd'hui pour analyser ce qui se produit lord de l'import des cours d'eau dans Georiviere. Voici mon retour :

Les données sont correctes. L'import des données fonctionne. En testant en local sur mon poste avec vos données j'arrive à les importer bien au-delà de 200 éléments. Par contre, lors de l'import j'observe deux chose :

Consommation mémoire excessive

Le script d'import consomme de la mémoire de manière linéaire mais en augmentation constante, sans qu'à priori il y ai de libération de mémoire à aucun moment.

Par exemple en important 400 éléments j'arrive à une consommation de plusieurs Go de RAM sur ma machine.

Je pense donc qu'il y a une fuite mémoire quelque part, mais il faudrait creuser pour trouver où.

En tout cas je pense que c'est cet élément qui est responsable de l'arrêt de votre script sur le serveur : à un moment il n'y a plus de mémoire et ça engendre un kill automatique du script.

La solution est soit d'augmenter la mémoire soit tout simplement de segmenter l'import et de créer un script qui appelle la commande d'import pour 10 éléments à chaque fois (et ainsi entre chaque import par lot d'éléments la mémoire consommée re-diminue donc on atteint jamais un seuil critique).

Une commande bash devrait permettre de le faire assez facilement.

Temps d'import exponentiel

Plus on a d'éléments dans la base, plus le temps de sauvegarde d'un nouvel élément est long. Ce n'est pas un problème critique à mon avis pour votre cas, il faut juste partir du principe que l'import mettra plusieurs heures à être effectué.

Par contre personnellement ça m'intrigue. J'ai cherché à comprendre ce qui prenait autant de temps et j'ai trouvé trois sauvegarde d'objets qui ralentissent l'import :

  • Morphology
  • Status
  • Altimétrie

Par contre je n'explique pas encore pourquoi la sauvegarde de ces objets est de plus en plus longue au fur et à mesure qu'il y a d'autres objets dans la base.

Je me suis demandé si on ne pouvait pas utiliser plutôt des méthodes comme asave() pour sauvegarder en asynchrone et gagner du temps ? Par exemple pour l'altimétrie qui selon moi n'est pas bloquant pour pouvoir créer un autre objet en parallèle.

Bref il y a surement un travail à faire de ce côté. Une chose est sur quand on importe des cours d'eau dans GeoRiviere il y a plein d'opération cachées qui créé des objets en cascade ensuite, ce qui fait que pour 300+ cours d'eau importés on se retrouve en réalité avec 1700+ objets créés.

Quelle réponse au problème ?

Je dirai qu'il faudrait essayer d'importer les données itérativement, lot par lot, sans chercher à importer le 14000 d'un seul coup. La mémoire du serveur sera ainsi moins sollicitée.

Pour augmenter la vitesse d'import il pourrait aussi être intéressant de vérifier que la base de données Postgres est bien configurée selon les ressources du serveur.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants