PHP et consommation mémoire

**heygeo** · 05/08/2010, 14h56

Bonjour,
J'ai créé pour ma société un framework qui fonctionne tres bien, hormis pour une chose : la consommation mémoire de mes scripts.
Je suis passé à PHP 5.3, esperant que le garbage collector allait faire du ménage, mais rien de mieux.
Je me suis donc lancé dans une enquète, aidé de mon fidèle assistant memory_get_usage.
Apres une enquete minutieuse, je me rends compte que c'est le code PHP en lui même qui prend plein de mémoire.
Je m'explique : je fais un require sur un fichier PHP un peu gros : 5500 lignes qui occupe 188 Ko sur mon disque.
C'est une classe, il n'y a pas de code interprété à ce moment là.
Et bien la memoire fait immédiatement un bon de 2.3 Mo !
Du coup, comme mon projet est assez gros, une fois que tous les fichiers utiles sont inclus, je ne peux descendre en dessous de 8Mo.
Est-ce normal ?
Merci de vos réponses !

**Oscar Hiboux** · 05/08/2010, 16h29

Utilisez-vous PHP via le module Apache, via CGI, FastCGI ?

**heygeo** · 05/08/2010, 16h48

Envoyé par Oscar Hiboux

Utilisez-vous PHP via le module Apache, via CGI, FastCGI ?

Pardon, j'ai oublié de préciser :

J'appelle le script via Apache tournant sur un serveur Linux.

**Oscar Hiboux** · 05/08/2010, 19h43

Es-tu tout de même parvenu à isoler le code problématique ? Essaye de trouver le fragment de code le plus court possible et expose le nous éventuellement...

Sinon, si tu es à l'aise en anglais tu peux jeter un œil à ce billet. Il y a qq idées à prendre (ou laisser) selon le cas.

**heygeo** · 11/08/2010, 10h35

Envoyé par Oscar Hiboux

Es-tu tout de même parvenu à isoler le code problématique ? Essaye de trouver le fragment de code le plus court possible et expose le nous éventuellement...

Sinon, si tu es à l'aise en anglais tu peux jeter un œil à ce billet. Il y a qq idées à prendre (ou laisser) selon le cas.

Et bien mon problème n'est pas un problème d'execution, mais de chargement du fichier php.

Je fais le test suivant :

Code :

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

<?php echo round(memory_get_usage()/(1024),2)." Ko";?>

J'obtiens 613.81 Ko, ce qui j'imagine est la mémoire utilisée de base par l'interpreteur PHP.

Ensuite j'ajoute une fonction de 1750 instructions dans le fichier :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
<?php
echo round(memory_get_usage()/(1024),2)." Ko";
function toto()
{
	$var="une chaine de caracteres";
	$var="une chaine de caracteres";
 
	[...] 1750 fois en tout
 
	$var="une chaine de caracteres";
}

J'obtiens 1107.12 Ko, c'est à dire que le chargement de ce fichier de 1750 instructions a utilisé 493.31 Ko de mémoire sans même que je n'ai exécuté quoi que ce soit.
Le fichier en lui même fait 18Ko.
Est-ce normal ? J'imagine que PHP fait une sorte de precompilation de mon fichier et stocke ce code précompilé dans la memoire ce qui fait que cela consomme de la memoire alors que rien n'a encore été éxécuté.
Peut-on demander a PHP d'avoir un autre comportement, de ne charger que ce qui est utile = executé ?

Cela m'interesserait que certains fassent le meme test que moi pour comparer les resultats.

Merci !

**Oscar Hiboux** · 11/08/2010, 16h00

Dans mon cas PHP tourne sous la forme d'un module Apache dans une machine virtuelle avec pour base Fedora. Le premier test me donne 90,3 Ko, tandis que le deuxième me donne 586,19 Ko.

En réduisant la taille des chaines de caractères la quantité de mémoire diminue, mais assez peu : en passant de "une chaine de caracteres" à "pouet" ça me donne 528,84 Ko.

Pour chaque bloc de 100 instructions que j'enlève je gagne à ~28,2 Ko, soit un total de ~493,3 Ko pour 17,5 blocs, les 90,3 Ko pour le reste, ce qui nous mène à ~583,6 Ko, un résultat assez proche des 586,19 Ko affichés plus haut.

**devuser** · 11/08/2010, 17h17

Bonjour,

A part peut être de changer,le comportement du moteur zend (à confirmer ...),je ne pense pas qu'on peut changer le cycle d'exécution du php ...

Mais,pour des cas ou les fonctions/classes,ne sont pas toujours nécessaires à l'exécution,(Par exemple,les fonctions qui sont utilisable si,et "seulement" si on a un résultat précis ou bien évènement de probabilité,...),on peut mettre ses fonctions,dans des page sépares,et utilisé include/require,avec des conditions.

Code php :

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

1
2
3
4
5
6
7
8
9
10
11
12
function _($function,$arg)
{
    if(!function_exists($function)
        include($function.'.php'); // l'autre fichier
    return $function($arg);
}
 
 
 
if($condition) _('toto',$arg);
 
echo round(memory_get_usage()/(1024),2)." Ko";

**Oscar Hiboux** · 11/08/2010, 20h26

Au fait, as-tu essayé d'installer APC (ou un autre accélérateur) ? Si ça se trouve ça sera quasiment identique en terme d'utilisation de mémoire (mais plus rapide). En tout cas ça vaut le coup d'essayer...

P.S. : APC place autant de code que possible en cache afin de réduire la quantité de code à recharger d'une interprétation à l'autre.

**heygeo** · 12/08/2010, 09h27

Envoyé par devuser

Bonjour,

A part peut être de changer,le comportement du moteur zend (à confirmer ...),je ne pense pas qu'on peut changer le cycle d'exécution du php ...

Mais,pour des cas ou les fonctions/classes,ne sont pas toujours nécessaires à l'exécution,(Par exemple,les fonctions qui sont utilisable si,et "seulement" si on a un résultat précis ou bien évènement de probabilité,...),on peut mettre ses fonctions,dans des page sépares,et utilisé include/require,avec des conditions.

C'est une bonne idée, mais le projet en question est vraiment tres lourd, il y a des centaines de fonctions, il faudrait pour systematiser ce comportement de facon générique, ça me semble difficile. Cependant j'ai quelques grosses fonctions que je vais mettre dans des fichiers separes comme tu dis. Merci du tuyau !

**RunCodePhp** · 12/08/2010, 10h50

Salut

Je tente de m'incruster dans la discussion, ça m'a l'air intéressant

Disons le de suite, je me suis jamais penché sur la gestion de le mémoire en Php, j'y connais pas grand chose à ce niveau en faite.

Mais j'ai réaliser quelques petits essai avec cette fonction memory_get_usage(), et là, ça m'inquiète au peu aussi.

Déjà, je pensais que faire un unset() détruisait un élément, variable, tableau, objet, etc ... que ça libérerait de la mémoire.
L'essai ne le démontre pas du tout.

Le petit test :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
// sur quelque lignes, à plusieur reprises :
$memoryUsage[] = memory_get_usage(true);
 
 
// A la fin :
$memoryUsage[] = memory_get_usage(true);
unset($BD);
$memoryUsage[] = memory_get_usage(true);
unset($Controller);
$memoryUsage[] = memory_get_usage(true);
unset($Seo);
$memoryUsage[] = memory_get_usage(true);
unset($Sess);
$memoryUsage[] = memory_get_usage(true);
unset($Href);
$memoryUsage[] = memory_get_usage(true);
unset($User);
$memoryUsage[] = memory_get_usage(true);
 
// Affiche les résultats
myPrint_r($memoryUsage);

Résultat du print_r :
[0] => 524288
[1] => 786432 -> Augmente : correspond à l'instanciation d'un Objet
[2] => 1310720 -> Augmente : Après inclusion des fonctions (entre autre)
[3] => 1572864 -> Augmente : Démarrage de la session (entre autre)
[4] => 2097152 -> Augmante : D'autres instanciation d'Objets
[5] => 3145728 -> Augmente : Après affichage (des echo ou HTML en faite)
[6] => 3145728 -> change pas
[7] => 3145728 -> change pas
[8] => 3145728 -> change pas
[9] => 3145728 -> change pas
[10] => 3145728 -> change pas
[11] => 3145728 -> change pas
[12] => 3145728 -> change pas

La mémoire ne fait qu'augmenter

Et les 7 dernières récup de mémoires ne changent jamais malgrè des unset().

Donc ça tourne autour des 3 Mo tout de même

Ce test est il fiable, peut on se baser la dessus (je dirais que non) ?
Ou alors le mémoire est gérée tout autrement, du coup c'est pas comme ça qu'il faut faire ?

Envoyé par heygeo

il y a des centaines de fonctions, il faudrait pour systematiser ce comportement de facon générique, ça me semble difficile. Cependant j'ai quelques grosses fonctions que je vais mettre dans des fichiers separes comme tu dis. Merci du tuyau !

Des centaines ? ça fait beaucoup, c'est vrai.
Je vais peut être dire une bêtise, mais est ce qu'il y aurait pas moyen de charger des fonction en exploitant (ou détournant) celui qui se fait avec les classe avec la fonction magique __autoload() ?

**grunk** · 12/08/2010, 11h21

3Mo pour un script ne me semble pas spécialement préoccupant. En faisant un hello world avec Zend Framework on est déjà pas loin des 2.5Mo.

Faut pas perdre de vue que cette consommation mémoire est un instantané et qu'à la fin du script la mémoire est (normalement) restituée.

Et les 7 dernières récup de mémoires ne changent jamais malgrè des unset().

Le fait que tu remplisses un tableau au fur et à mesure n'est pas annondin à mon avis.
Perso quand j'initialise mon framework, que je fait un affichage et qu'ensuite j'unset mes variable de vue je perd bien les quelques octet que ces variables utilisaient :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
ini_set('display_errors', 'on');
//Inclusions minimales
require_once "includes/core/Config.php";
require_once 'includes/core/Twig/Autoloader.php';
Config::register();
 
try{
	$configIni = Config_Ini::getInstance(ROOT_LIB.'config.ini',MODE_CONFIG);
	Util_Registry::set('Config',$configIni);
	define('ROOT_PATH',$configIni->root);
}
catch(Util_ExceptionHandler $e){
	echo $e->getError(true);
}
 
//Réglage horaire
date_default_timezone_set('Europe/Paris');
 
Twig_Autoloader::register();
$loader = new Twig_Loader_Filesystem(ROOT_PATH.'includes/template/');
$twig 	= new Twig_Environment($loader, array(
  'cache' 		=> ROOT_PATH.'includes/template/cache/',
  'auto_reload'	=> false
));
Util_Registry::set('twig',$twig);
 
$twig->addExtension(new Twig_Extension_Filters_GetText);
 
$view	= array();
 
$module 		= (isset($_GET['mod']))?htmlspecialchars($_GET['mod']):'';
$action 		= (isset($_GET['act']))?htmlspecialchars($_GET['act']):'';
$view['erreur']     = (isset($_GET['el']))?htmlspecialchars($_GET['el']):'';
 
$view['module']    = $module;
$view['action']     = $action;
 
if(isset($module) && !empty($module))
{
	if(file_exists(ROOT_PATH.'includes/modules/'.$module.'/'.$action.'.php'))
	{
		$template = $twig->loadTemplate('struct/base.html');
		echo $template->render($view);
	}
	else
	{
		$template = $twig->loadTemplate('error/modules.html');
		echo $template->render($view);
	}
 
}
else
{
	$template = $twig->loadTemplate('struct/default.html');
		echo $template->render($view);
}
echo round(memory_get_usage()/(1024),2)." Ko";
unset($twig);
unset($template);
unset($view);
echo '<br />'.round(memory_get_usage()/(1024),2)." Ko";

Je passe de 405.1ko à 404ko

**Thes32** · 12/08/2010, 11h35

Envoyé par RunCodePhp

Déjà, je pensais que faire un unset() détruisait un élément, variable, tableau, objet, etc ... que ça libérerait de la mémoire.

ça me parait bizarre que ça marche pas avec test tests, Perso j'utilise généralement unset pour éviter le dépassement de memory_limit sur des scripts d'imports et autres de grosses quantités de données (en CLI) et ça marche.

**RunCodePhp** · 12/08/2010, 12h14

Envoyé par grunk

Le fait que tu remplisses un tableau au fur et à mesure n'est pas annondin à mon avis.

J'ai pas d'explication, mais je suis de ton avis.
Bien vu

En le faisant directe avec des echo, là, ça bouge, et ça diminue.

1/ 1355320
2/ 1975440
3/ 3016056
4/ 3017856
5/ 3017776
6/ 3017688
7/ 3017632
8/ 3017576
9/ 3017496
10/ 3017408
11/ 3017328

Ca diminue pas des masses, mais c'est un bon point.
Donc je pensais que je détruisais les Objets les plus volumineux, faut croire que ce n'est du tout le cas.
Même pas 1300 Octets détruits

Donc me reste à savoir qui me bouffe de la mémoire comme ça, et voir s'il y aurait pas moyen de le détruire, et au plus tôt.

Il me semblais tout de même avoir lu, et concernant les Objets, que Php libérait de la mémoire lors qu'un Objet était utilisé lors de sa dernière occurrence ou utilisation (pas certain du terme : occurrence).

Vu que les echo ont été effectués tout à la fin, j'ai l'impression que ce n'est pas le cas, car c'est en détruisant quelque uns explicitement par unset() qu'ils ont été détruits.
Mais c'est peut être des idées reçues,ou confusions.

**heygeo** · 12/08/2010, 13h07

Envoyé par RunCodePhp

Déjà, je pensais que faire un unset() détruisait un élément, variable, tableau, objet, etc ... que ça libérerait de la mémoire.
L'essai ne le démontre pas du tout.

A ce sujet lire l'article ci-dessous :

http://blog.pascal-martin.fr/post/ph...mation-memoire

Si j'ai bien compris, pour resumer, avec PHP 5.2 et inferieur, le Garbage Collector ne passe qu'a la fin du script. Donc rien ne peut etre libéré en cours de route.

Edit : non en fait le pb se pose simplement pour les références cycliques, le garage collector faisant son travail pour le reste de facon reguliere. Mais avec les ref cyclique on peut facilement se retourver avec un programme glouton

Par contre, avec PHP 5.3, le garbage collector est capable de resoudre des references cycliques. On peut même appeler soi-même le garbage collector avec gc_collect_cycles().

Rem : ca ne change rien à mon histoire de fichiers php trop gros

Des centaines ? ça fait beaucoup, c'est vrai.
Je vais peut être dire une bêtise, mais est ce qu'il y aurait pas moyen de charger des fonction en exploitant (ou détournant) celui qui se fait avec les classe avec la fonction magique __autoload() ?

Peut-etre...ca veut dire tout de meme que je devrais mettre chaque fonction dans un fichier separé

**heygeo** · 12/08/2010, 13h10

Envoyé par Oscar Hiboux

Au fait, as-tu essayé d'installer APC (ou un autre accélérateur) ? Si ça se trouve ça sera quasiment identique en terme d'utilisation de mémoire (mais plus rapide). En tout cas ça vaut le coup d'essayer...

Je vais tenter le coup, mais l'administrateur du serveur a pas l'air chaud...

**heygeo** · 12/08/2010, 13h19

Envoyé par Oscar Hiboux

Pour chaque bloc de 100 instructions que j'enlève je gagne à ~28,2 Ko, soit un total de ~493,3 Ko pour 17,5 blocs, les 90,3 Ko pour le reste, ce qui nous mène à ~583,6 Ko, un résultat assez proche des 586,19 Ko affichés plus haut.

Donc toute instruction PHP, meme si elle n'est pas exécutée, consomme 0.3 Ko de mémoire. Fichtre.

**kaymak** · 12/08/2010, 18h36

Envoyé par heygeo

Bonjour,
J'ai créé pour ma société un framework qui fonctionne tres bien, hormis pour une chose : la consommation mémoire de mes scripts.
Je suis passé à PHP 5.3, esperant que le garbage collector allait faire du ménage, mais rien de mieux.
Je me suis donc lancé dans une enquète, aidé de mon fidèle assistant memory_get_usage.
Apres une enquete minutieuse, je me rends compte que c'est le code PHP en lui même qui prend plein de mémoire.
Je m'explique : je fais un require sur un fichier PHP un peu gros : 5500 lignes qui occupe 188 Ko sur mon disque.
C'est une classe, il n'y a pas de code interprété à ce moment là.
Et bien la memoire fait immédiatement un bon de 2.3 Mo !
Du coup, comme mon projet est assez gros, une fois que tous les fichiers utiles sont inclus, je ne peux descendre en dessous de 8Mo.
Est-ce normal ?
Merci de vos réponses !

Hello,

3mo c'est peanut pour une application. N'importe quel fw, cms avec un minimum de fonctionnalitée utilise au moins 15 mo par requête.

Aussi dans le cas de l'occupation mémoire par déclaration de classe/fonction il n'y à aucun autre moyen que l'accélérateur (apc, xcache, eaccelerator etc) pour soulager le serveur.
D'ailleurs cela à deux fonctions
1 optimiser l'utilisation mémoire
2 optimiser les cycles CPU.

Le gc n'intervient que, et uniquement, pour les variables déclarées, fonctions lamdba incluses je pense.

a plus

**Oscar Hiboux** · 13/08/2010, 02h07

C'est peanut ? Ah... alors parce que beaucoup sont médiocres il faudrait signer également dans ce registre ? 15 Mo / requête ça donne vraiment le vertige !

@heygeo : courage, lâche pas avec ton administrateur, c'est vraiment trivial d'installer APC...

D'expérience unset n'a jamais fait de miracle effectivement, c'est même presque plus une prière qu'une instruction...

**RunCodePhp** · 13/08/2010, 07h46

Envoyé par Oscar Hiboux

D'expérience unset n'a jamais fait de miracle effectivement, c'est même presque plus une prière qu'une instruction...

Houlà

Quel serait le moyen de détruire des éléments de manière plus efficace alors ?
Les réinitialiser, comme par exemple : $Objet = NULL; ?

**heygeo** · 13/08/2010, 10h23

Envoyé par kaymak

Hello,
3mo c'est peanut pour une application. N'importe quel fw, cms avec un minimum de fonctionnalitée utilise au moins 15 mo par requête.

Je trouve cela enorme, mais au vu de mes tests ca ne m'etonne pas.

Envoyé par kaymak

Aussi dans le cas de l'occupation mémoire par déclaration de classe/fonction il n'y à aucun autre moyen que l'accélérateur (apc, xcache, eaccelerator etc) pour soulager le serveur.
D'ailleurs cela à deux fonctions
1 optimiser l'utilisation mémoire
2 optimiser les cycles CPU.

C'est bien ce que je craignais

Envoyé par kaymak

Le gc n'intervient que, et uniquement, pour les variables déclarées, fonctions lamdba incluses je pense.

Là je ne comprends pas tout, variables déclarées, c'est à dire ? Perso je declare/initialise toujours mes variables en PHP (j'ai commencé avec du C++ c'est pour ca

)
Les fonctions anonymes, c'est nouveau en PHP 5.3 c'est ca ?

PHP et consommation mémoire

Langage PHP

Discussions similaires

Partager

Partager