Problèmes de mémoire à l’import
L’import consomme beaucoup de mémoire et peut amener à tuer le worker.
Plusieurs pistes ont été envisagée et testées :
- le parsing en ruby de json est peu efficace
- on fait un broadcast en batch à la fin de la transaction necessitant de tout garder en mémoire
- l’objet de reporting garde tous les rows
Autres remarques : on broadcast les changement de layer à chaque changement de row pour mettre à jour la date. Ça doit pouvoir s’optimiser.
Chaque hypothèse a été testée sur le même jeu de données : un geojson de près de 8000 lignes https://opendata.paris.fr/explore/dataset/les-arbres-plantes/information/
La consommation mémoire a été mesurée avec procpath sur tous les process ruby
(c’est pour ça qu’il y a plusieurs courbes).
Situation initiale
Parsing geojson
On test d’utiliser ogr2ogr pour générer un geojsonl (ou geojsonSeq) où chaque feature est une ligne, permettant en ruby de parser au fur et à mesure. Comme dans !730
Broadcast en batch
On n’encapsule pas dans BatchRowBroadcast
https://gitlab.com/CodeursEnLiberte/cocarto/-/blob/main/app/models/import/operation.rb?ref_type=heads#L179-188
Par contre le temps d’execution est significativement plus lent (environ trois fois plus long, mais ça n’a pas été mesuré rigoureusement)
Reporting
On commente la ligne https://gitlab.com/CodeursEnLiberte/cocarto/-/blob/main/app/services/importers/base.rb?ref_type=heads#L94
Ces trois opérations combinées
Pistes
- Utiliser le parsing geojsonl, qui se révèlera particulièrement utile avec des fichiers plus gros
- Effectivement utiliser l’import en bulk et faire des batchs (1000 lignes ?) ce qui permet de garder le broadcast en batch
- Ne pas faire de reporting sur les rows insérés sans problème
À résoudre
Il reste un pic de consommation mémoire à la fin à expliquer