Explication détaillée de la fuite de mémoire PHP

La fuite de mémoire fait référence au phénomène selon lequel la mémoire est demandée pendant l'exécution du programme, mais n'est pas libérée à temps une fois l'utilisation terminée, pour les programmes ordinaires avec une durée d'exécution courte, le problème n'est peut-être pas si évident, mais. pour les programmes à exécution longue Cela est plus évident pour les programmes tels que les serveurs Web, les processus en arrière-plan, etc. Au fur et à mesure que le système s'exécute, la mémoire occupée continuera d'augmenter et peut planter en raison d'une utilisation excessive de la mémoire, ou être tuée par le système ( MOO).

Fuites de mémoire en PHP

PHP est un langage de haut niveau Il n'y a pas de concept de mémoire au niveau du langage, il n'est donc pas nécessaire de demander ou de libérer activement de la mémoire pendant l'utilisation. au niveau du code utilisateur PHP Il n'y a plus de notion de fuite mémoire.

Si votre programme PHP présente une fuite de mémoire ou si des variables volumineuses ne sont pas publiées à temps, il y a alors un problème avec l'implémentation de l'extension tierce elle-même.

Fuite de mémoire causée par PHP-FPM

Voici une brève introduction au principe de fonctionnement du mode nginx+php-fpm :

1. Le serveur nginx débourse n processus enfants (workers), et le gestionnaire php-fpm débourse n processus enfants.

2. Lorsqu'il y a une demande utilisateur, un travailleur de nginx reçoit la demande et la jette dans le socket.

3. Le sous-processus inactif de php-fpm écoute les requêtes dans le socket, reçoit et traite les requêtes.

Je voudrais ici me concentrer sur la troisième étape. La troisième étape concerne le cycle de vie du processus php-fpm. Le cycle de vie d'un php-fpm ressemble à ceci : initialisation du module (MINIT) -> activation du module (RINIT) -> désactivation du module (RSHUTDOWN) -> Traitement de la demande -> Désactivation du module (RSHUTDOWN)...... Activation du module (RINIT) -> Désactivation du module (RSHUTDOWN) -> Dans le cycle de vie d'un processus php-fpm, il y aura plusieurs processus d'activation de module (RINIT) -> traitement des demandes -> désactivation de module (RSHUTDOWN). Le processus général de ce "traitement des requêtes" est le suivant : PHP lit le fichier PHP correspondant, y effectue une analyse lexicale, génère l'opcode et la machine virtuelle zend exécute l'opcode.

La memory_limit dans le fichier de configuration PHP limite en fait uniquement la mémoire pour le "traitement des requêtes". Ce paramètre n'a donc rien à voir avec la mémoire occupée par le processus php-fpm.

Alors, y a-t-il un moyen d'éviter ce problème ?
Il y a un paramètre pm.max_requests dans php-fpm.conf, qui est équivalent à PHP_FCGI_MAX_REQUESTS. Cette valeur indique le nombre de requêtes traitées par un processus fpm avant d'être automatiquement supprimé et qu'un nouveau processus soit démarré.

Débogage et outils de fuite de mémoire

Les programmes de fuite de mémoire sont généralement faciles à trouver, car les symptômes se manifestent par une croissance continue de l'utilisation de la mémoire. Après avoir découvert que la mémoire continue de croître, nous devons déterminer. quelle en est la cause. Si une fuite de mémoire se produit, vous devez souvent utiliser certains outils pour vous aider à la retrouver. Nous pouvons utiliser deux outils : la détection de fuite de mémoire intégrée à PHP et l'analyse des fuites de mémoire Valgrind.

Recommandations associées :

Partage d'exemples sur la façon de gérer les fuites de mémoire JavaScript

Photo du noyau PHP des fuites de mémoire et des nouveaux déchets mécanisme de collecte Introduction à l'article

Qu'est-ce qu'une fuite de mémoire, les causes et les méthodes de prévention des fuites de mémoire

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!