Discussion :

[Aurélien LEQUOY]

Pour résumer c'est une vulgaire extraction d'une table envoyé au navigateur en fichier CSV à la volé.


Le code se situe dans une fonction d'une class :


Garbage Colletor enabled (défaut) : OUI
utilisation de la mémoire : 3139.66 Mo

exécution de la requête (environ 200 000 lignes sur 25 colones)
22.28 Mo

jusqu'à là pas de problème


ensuite vient le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
$tab = array();
		while ($tab = mysql_fetch_array($res,MYSQL_NUM)) { 
			//echo implode("`|", $tab) . "\n<br />";
			echo round(memory_get_usage()/(1024*1024),2)." Mo<br />";
			unset($tab);
			gc_collect_cycles();
		}

résultats :

1er ligne : 22.28 Mo
60164 ligne : 127.85 Mo


j'ai retirer les lignes dans la boucle et juste ce code là pose problème :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$tab = array();
		while ($tab = mysql_fetch_array($res,MYSQL_NUM)) { 
 
		}

j'ai essayé avec d'autre fonction mysql comme mysql_fetch_object etc... mais cela ne change rien.

[rawsrc]

Salut,

je ne sais pas si tu travaille sur MySQL mais il t'est possible de créer le .csv avec le MySQL et de servir le résultat tel quel avec PHP (plus de problème de mémoire)
Quelque chose du genre :

Code sql :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
SELECT ...
FROM table
INTO OUTFILE '/tmp/csv_output.csv'
FIELDS TERMINATED BY ','
ENCLOSED BY '"'
LINES TERMINATED BY '\n'

A creuser...

[Aurélien LEQUOY]

Effectivement ça résout ce problème là, quoi que non car le serveur BDD est pas sur la même machine que le serveur PHP. Enfin ya toujours moyen de faire de la bidouille, mais ça ne résout pas le problème de fond.

Mais c'est un chose récurrente chez moi, car je commence de plus en plus à utiliser php en langage de batch pour des traitements de données (grab etc...)

En écrivant comme un goret avec une fonction appelé dans une boucle on arrive à récupérer de la mémoire, mais c'est beaucoup moins performant en vitesse d’exécution.

[rawsrc]

C'est clair qu'avec ton code tu vas récupérer en mémoire l'intégralité de ton tableau. Je ne sais pas l'impact d'une autre approche : si par exemple tu remplissais au fur et à mesure un fichier .csv toutes les 1000 lignes :
avec quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

file_put_contents($file, $data, FILE_APPEND | LOCK_EX);

[Aurélien LEQUOY]

Juste le fait de boucler dans rien faire pose problème, alors le fait d'ajouter le résultat dans un fichier ne ferait qu'empirer.


petite précision :

php -v
PHP 5.3.17-1~dotdeb.0 with Suhosin-Patch (cli) (built: Sep 14 2012 11:40:39)
Copyright (c) 1997-2012 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
    with Suhosin v0.9.33, Copyright (c) 2007-2012, by SektionEins GmbH

serveur : 
3GHz
4Go de ram

[gene69]

ça ne sert à rien, c'est pas l'appel adapté:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

gc_collect_cycles();

d'une part la collecte doit te retourner 0 à chaque fois (ton tableau c'est pas des variables à référence circulaire), d'autre par le garbage collector s’exécute de façon (pseudo) non déterministe, va voir les parametres php.ini.

La mémoire est consommée jusqu'à ce qu'il n'y en ai plus dispo. tant que tu es dans la limite autorisée, laisse php consommer ce dont il a besoin. Quand il arrive au max, il libère les variables non référencées et recycle la mémoire.

L'idée générale c'est que le GC consomme plus de perf que laisser les mémoires en place et attendre la fin de l'exec du processus php et que l'os récupère la mémoire.

si ton php utilise trop de mémoire, tu lui baisses la mémoire autorisée. Tu ne reçois pas d'erreur? alors go.