Discussion :

[Eulmich]

Bonjour,
je rencontre un problème assez casse tête pour traiter un import de données à partir de fichiers via l'application SugarCRM.
En gros j'extrais un fichier CSV que je parcours ligne par ligne : pour chaque ligne, on vérifie en base si cela correspond à un enregistrement connu ou non et on réalise un INSERT ou un UPDATE selon les cas.
Le problème est que la mémoire utilisée par le script ne cesse d'augmenter jusqu'à faire sauter le script, même si je monte jusque 512M (ce qui est déjà un peu énorme à mon avis...)

Détail important, tout ce qui est manipulation des données et accès à la base est fait via le framework Sugar, auquel je dois toucher le moins possible. Et c'est justement les appels à ce framework qui augmentent la mémoire utilisée...

Je me retrouve donc un peu coincé. J'imagine 2 solutions qui doivent bien exister, mais je ne sais pas trop comment m'y prendre :
1. si mon fichier CSV est trop volumineux, il est splitté en fichiers plus petits. Est-il possible de lancer un nouveau script pour chaque fichier ? (un thread ou quelque chose comme ça?)
2. si j'identifie quelles variables sont consommatrices (j'en ai déjà une bonne idée en regardant avec get_memory_usage), ai-je moyen de libérer
explicitement la mémoire? J'ai essayé un simple unset mais ça ne donne rien...

D'avance merci pour votre aide!
Michel

[Rakken]

Pour ce que j'en sais, l'appel à unset doit effectivement libérer la mémoire (avec une petite astuce, si tu as une variables globales et que tu fais ton unset dans une fonction, ca ne détruit que la variable visible dans la fonction, pas la globale).

Sur un problème comme ca, tu as évidement une fuite mémoire, et vu son importance, il faut d'abord commencer à chercher ou est "empilée" la mémoire, avant même de songer à faire des free.

Sinon au pire, pour le split, c'est techniquement faisable.
Tu as ta page et tu lui envoies le fichier csv. Tu sauvegardes le fichier et tu recharges ta page, avec un parametre $borneMin à zéro.
Tu traites les x premiere lignes et tu recharges à nouveau ta page avec $borneMin qui vaut $borneMin + x.
Tu relis ton fichier en ignorant les $borne_min premières lignes et traite les x suivantes et ainsi de suite jusqu'a ce que $borneMin soit plus grand que le nombre de ligne de ton fichier.

Faire ca pour un problème de mémoire, c'est pas terrible, mais ca doit marcher. Mais franchement je pense qu'il y a un soucis dans l'algo de lecture de fichier et ca vaut le coup de se prendre la tête une heure ou deux pour trouver le soucis plutot que de commencer à t'em*** avec des splits.

[Eulmich]

Merci pour ta réponse Rakken.

C'est clair qu'il y a une fuite mémoire, mais bon, après analyse, il y en a un paquet et elles se situent au coeur du framework Sugar... Je n'ai donc pas de solution de ce côté là.

Pour le split, c'est en effet assez emm..., surtout que mon script est destiné à être exécuté en batch et donc pas via une page mais en liggne de commande, ce qui change légèrement le contexte...

Bref, j'ai finalement trouvé une excellente solution sous réserve que mon client accepte, c'est de passer à la version 5.3 de PHP, qui inclut ENFIN un vrai garbage collector.


Exemple : je testais hier un fichier de 50000 lignes, ça sautait au bout de 25000 lignes avec 1Go de mémoire!
Avec PHP 5.3 , la mémoire est libérée régulièrement et mon script ne dépasse jamais les 50 Mo d'utilisation mémoire!

Pour ceux que ça intéresse :
PHP 5.3 : Garbage Collector et consommation mémoire

[Eulmich]

Bon, dernier post histoire de clore le topic :

PHP 5.3 est encore très récent (30 juin 2009), et il y a quelques incompatibilités qui rendent le risque encore trop important pour migrer une grosse application comme SugarCRM.
Vu que mon script s'éxécute en batch nocturne, je suis donc passé par un script shell qui appelle successivement un script qui split les fichiers, puis boucle sur un second script qui réalise le traitement des données pour les fichiers réduits. La mémoire utilisée est ainsi libérée pour chaque nouvel appel PHP. C'est un peu tordu mais ça marche