Augmentation de la limite de mémoire de PHP. À quel moment cela devient-il insensé ?

Question

Dans un système sur lequel je travaille actuellement, il y a un processus qui charge une grande quantité de données dans un tableau pour les trier, les agréger ou autre. Je sais que ce processus doit être optimisé pour l'utilisation de la mémoire, mais à court terme, il doit simplement fonctionner.

Compte tenu de la quantité de données chargées dans le tableau, nous nous heurtons sans cesse à la limite de la mémoire. Elle a été augmentée plusieurs fois, et je me demande s'il y a un moment où l'augmenter devient généralement une mauvaise idée ou est-ce que uniquement une question de quantité de RAM sur la machine ?

La machine dispose de 2 Go de RAM et la limite de mémoire est actuellement fixée à 1,5 Go. Nous pouvons facilement ajouter plus de RAM à la machine (et nous le ferons de toute façon).

D'autres personnes ont-elles rencontré ce genre de problème ? et quelles ont été les solutions ?

Answer 1

La configuration de l memory_limit de PHP s'exécutant en tant que module Apache pour le serveur de pages web doit prendre en compte le nombre de processus Apache que vous pouvez avoir en même temps sur la machine -- voir la page MaxClients option de configuration pour Apache.

Si MaxClients est de 100 et que vous disposez de 2 000 Mo de RAM, un calcul très rapide montrera que vous ne devez pas utiliser plus de 20 Mo *(car 20 Mo * 100 clients = 2 Go de RAM, c'est-à-dire la quantité totale de mémoire dont dispose votre serveur)* pour la valeur de memory_limit.

Et ceci sans tenir compte du fait qu'il y a probablement d'autres choses qui fonctionnent sur le même serveur, comme MySQL, le système lui-même, ... Et qu'Apache utilise probablement déjà de la mémoire pour lui-même.

Bien sûr, il s'agit également d'un "scénario du pire", qui considère que chaque page PHP utilise la quantité maximale de mémoire qu'elle peut.

Dans votre cas, si vous avez besoin d'une si grande quantité de mémoire pour une seule tâche, je n'augmenterais pas la valeur de l'espace mémoire de l'ordinateur. memory_limit pour PHP fonctionnant comme un module Apache.

Au lieu de cela, je lancerais ce travail à partir de la ligne de commande (ou via une tâche cron) et spécifier une valeur plus élevée memory_limit spécifiquement dans ce seul et unique cas.

Cela peut être fait avec le -d de php, comme :

$ php -d memory_limit=1GB temp.php
string(3) "1GB"

Considérant, dans ce cas, que temp.php ne contient que :

var_dump(ini_get('memory_limit'));

À mon avis, c'est beaucoup plus sûr que d'augmenter la limite de mémoire du module PHP d'Apache - et c'est ce que je fais habituellement lorsque j'ai un grand ensemble de données, ou des données vraiment lourdes que je ne peux pas optimiser ou paginer.

Si vous devez définir plusieurs valeurs pour l'exécution du CLI PHP, vous pouvez également lui demander d'utiliser un autre fichier de configuration, au lieu du php.ini par défaut, avec l'option -c option :

php -c /etc/phpcli.ini temp.php

De cette façon, vous avez :

• /etc/php.ini pour Apache, avec de faibles memory_limit , faible max_execution_time , ...
• et /etc/phpcli.ini pour les lots exécutés en ligne de commande, avec pratiquement aucune limite

Cela garantit que vos lots pourront être exécutés - et que vous aurez toujours la sécurité pour votre site web ( memory_limit et max_execution_time étant des mesures de sécurité)

Néanmoins, si vous avez le temps d'optimiser votre script, vous devriez le faire ; par exemple, dans ce genre de situation où vous devez traiter beaucoup de données, la pagination est indispensable ;-)

Answer 2

Avez-vous essayé de diviser l'ensemble de données en plusieurs parties et de ne traiter qu'une partie à la fois ?

Si vous récupérez les données à partir d'un fichier disque, vous pouvez utiliser la fonction fread() pour charger de plus petits morceaux, ou une fonction une sorte de requête de base de données sans tampon en cas de base de données.

Je n'ai pas vérifié PHP depuis la version 3.quelque chose, mais vous pourriez aussi utiliser une forme de cloud computing. Un jeu de données de 1 Go semble être assez gros pour être traité sur plusieurs machines.

Answer 3

Étant donné que vous savez qu'il y a des problèmes de mémoire avec votre script qui doivent être corrigés et que vous ne cherchez que des solutions à court terme, alors je n'aborderai pas les moyens de aller sur le profilage et de résoudre vos problèmes de mémoire. On dirait que vous allez y arriver.

Donc, je dirais que les principales choses que vous devez garder à l'esprit sont :

• Charge mémoire totale du système
• Capacités du système d'exploitation

Le PHP n'est qu'un petit composant du système. Si vous lui permettez de consommer une grande quantité de votre RAM, alors les autres processus en souffriront, ce qui pourrait à son tour affecter le script lui-même. Notamment, si vous extrayez beaucoup de données d'une base de données, votre SGBD peut avoir besoin de beaucoup de mémoire pour créer des ensembles de résultats pour vos requêtes. Comme solution rapide, vous pouvez identifier toutes les requêtes que vous exécutez et libérer les résultats dès que possible afin de vous donner plus de mémoire pour un travail de longue durée.

En termes de capacités du système d'exploitation, vous devez garder à l'esprit que les systèmes 32 bits, sur lesquels vous travaillez probablement, ne peuvent adresser que jusqu'à 4 Go de RAM sans manipulation spéciale. Souvent, la limite peut être bien inférieure en fonction de l'utilisation qui en est faite. Certains chipsets et configurations de Windows peuvent en fait avoir moins de 3 Go disponibles pour le système, même si 4 Go ou plus sont physiquement installés. Vous devez vérifier la capacité de votre système.

Vous dites que vous avez augmenté la limite de mémoire plusieurs fois, donc manifestement ce travail prend de plus en plus d'ampleur. Si vous en êtes à 1,5 Go, même l'installation de 2 Go de RAM supplémentaires ne sera qu'un bref sursis.

D'autres personnes ont-elles rencontré ce genre de problème ? et quelles ont été les solutions ?

Je pense que vous savez probablement déjà que la seule vraie solution est de décomposer et de passer le temps d'optimiser le script rapidement, ou vous vous retrouverez avec un travail qui sera trop gros pour être exécuté.