🚕 🙁 🐍 Un guide pratique pour gérer les fuites de mémoire dans Node.js 😱 ☝🏼 💇🏻

Les fuites de mémoire sont similaires aux entités parasites sur une application. Ils pénètrent tranquillement dans le système, au début sans causer de mal. Mais si la fuite s'avère suffisamment forte, elle peut entraîner la catastrophe de l'application. Par exemple - pour le ralentir fortement ou simplement pour le «tuer». L'auteur de l'article, dont nous publions la traduction aujourd'hui, suggère de parler des fuites de mémoire en JavaScript. En particulier, nous parlerons de la gestion de la mémoire en JavaScript, comment identifier les fuites de mémoire dans les applications réelles et comment traiter les fuites de mémoire.

Qu'est-ce qu'une fuite de mémoire?

Une fuite de mémoire est, au sens large, un morceau de mémoire alloué à une application dont cette application n'a plus besoin, mais qui ne peut pas être renvoyée au système d'exploitation pour une utilisation future. En d'autres termes, il s'agit d'un bloc de mémoire qui est capturé par l'application sans l'intention d'utiliser cette mémoire à l'avenir.

Gestion de la mémoire

La gestion de la mémoire est un mécanisme d'allocation de mémoire système à une application qui en a besoin et un mécanisme de renvoi de mémoire inutile au système d'exploitation. Il existe de nombreuses approches de la gestion de la mémoire. L'approche utilisée dépend du langage de programmation utilisé. Voici un aperçu de plusieurs approches courantes de la gestion de la mémoire:

. . . , . C C++. , , malloc free, .
. , , , . , , , . , , , , . . — JavaScript, , JVM (Java, Scala, Kotlin), Golang, Python, Ruby .
Application du concept de propriété de la mémoire. Avec cette approche, chaque variable doit avoir son propre propriétaire. Dès que le propriétaire est hors de portée, la valeur de la variable est détruite, libérant de la mémoire. Cette idée est utilisée dans Rust.

Il existe d'autres approches de la gestion de la mémoire utilisées dans différents langages de programmation. Par exemple, C ++ 11 utilise l'idiome RAII , tandis que Swift utilise le mécanisme ARC . Mais en parler dépasse le cadre de cet article. Afin de comparer les méthodes de gestion de la mémoire ci-dessus, pour comprendre leurs avantages et leurs inconvénients, nous avons besoin d'un article séparé.

JavaScript, un langage sans lequel les programmeurs Web ne peuvent pas imaginer leur travail, utilise l'idée de garbage collection. Par conséquent, nous parlerons davantage du fonctionnement de ce mécanisme.

Collecte de déchets JavaScript

Comme déjà mentionné, JavaScript est un langage qui utilise le concept de garbage collection. Pendant le fonctionnement des programmes JS, un mécanisme appelé garbage collector est périodiquement lancé. Il découvre quelles parties de la mémoire allouée sont accessibles à partir du code d'application. Autrement dit, quelles variables sont référencées. Si le garbage collector découvre qu'un morceau de mémoire n'est plus accessible à partir du code d'application, il libère cette mémoire. L'approche ci-dessus peut être mise en œuvre en utilisant deux algorithmes principaux. Le premier est ce que l'on appelle l'algorithme Mark and Sweep. Il est utilisé en JavaScript. Le deuxième est le comptage des références. Il est utilisé en Python et PHP.

Phases Mark (marquage) et Sweep (nettoyage) de l'

algorithme Mark and Sweep Lors de la mise en œuvre de l'algorithme de marquage, une liste de nœuds racine représentée par des variables d'environnement globales (c'est un objet dans le navigateurwindow) est d'abord créée, puis l'arborescence résultante est analysée des nœuds racine aux feuilles marqués de tous rencontré sur le chemin des objets. La mémoire du tas occupée par des objets sans étiquette est libérée.

Fuites de mémoire dans les applications Node.js

À ce jour, nous avons analysé suffisamment de concepts théoriques liés aux fuites de mémoire et à la collecte des ordures. Donc, nous sommes prêts à voir à quoi tout cela ressemble dans les applications réelles. Dans cette section, nous allons écrire un serveur Node.js qui a une fuite de mémoire. Nous essaierons d'identifier cette fuite à l'aide de divers outils, puis nous l'éliminerons.

▍ Familiarité avec un code présentant une fuite de mémoire

À des fins de démonstration, j'ai écrit un serveur Express qui a une route de fuite de mémoire. Nous allons déboguer ce serveur.

const express = require('express')

const app = express();
const port = 3000;

const leaks = [];

app.get('/bloatMyServer', (req, res) => {
  const redundantObj = {
    memory: "leaked",
    joke: "meta"
  };

  [...Array(10000)].map(i => leaks.push(redundantObj));

  res.status(200).send({size: leaks.length})
});

app.listen(port, () => console.log(`Example app listening on port ${port}!`));

Il existe un tableau leaksqui sort du domaine d'application du code de traitement des demandes d'API. Par conséquent, chaque fois que le code correspondant est exécuté, de nouveaux éléments sont simplement ajoutés au tableau. Le tableau n'est jamais effacé. Étant donné que le lien vers ce tableau ne disparaît pas après avoir quitté le gestionnaire de demandes, le garbage collector ne libère jamais la mémoire qu'il utilise.

▍Appeler une fuite de mémoire

Nous arrivons ici au plus intéressant. De nombreux articles ont été écrits sur la façon node --inspectde déboguer les fuites de mémoire du serveur, après avoir rempli le serveur de requêtes en utilisant quelque chose comme l' artillerie . Mais cette approche présente un inconvénient important. Imaginez que vous ayez un serveur API qui a des milliers de points de terminaison. Chacun d'eux prend beaucoup de paramètres, dont le code spécifique sera appelé dépend des caractéristiques de celui-ci. Par conséquent, dans des conditions réelles, si le développeur ne sait pas où se trouve la fuite de mémoire, il devra accéder à chaque API plusieurs fois en utilisant toutes les combinaisons possibles de paramètres pour remplir la mémoire. Pour moi, ce n'est pas facile. Cependant, la solution à ce problème est facilitée en utilisant quelque chose commegoreplay - un système qui vous permet d'enregistrer et de "jouer" du trafic réel.

Afin de faire face à notre problème, nous allons faire le débogage en production. Autrement dit, nous autoriserons notre serveur à déborder de mémoire pendant son utilisation réelle (car il reçoit une variété de demandes d'API). Et après avoir constaté une augmentation suspecte de la quantité de mémoire qui lui est allouée, nous procéderons au débogage.

▍ Vidage de tas

Afin de comprendre ce qu'est un vidage de tas, nous devons d'abord découvrir la signification du concept de tas. Si vous décrivez ce concept aussi simplement que possible, il s'avère que le tas est l'endroit où tout ce que la mémoire est allouée tombe. Tout cela est sur le tas jusqu'à ce que le ramasse-miettes en retire tout ce qui est jugé inutile. Un vidage de segment de mémoire est un instantané de l'état actuel du segment de mémoire. Le vidage contient toutes les variables internes et variables déclarées par le programmeur. Il représente toute la mémoire allouée sur le tas au moment de la réception du vidage.

Par conséquent, si nous pouvions d'une manière ou d'une autre comparer le vidage de tas du serveur qui venait de commencer avec le vidage du tas de serveur, qui fonctionnait depuis longtemps et débordait de mémoire, nous pourrions identifier les objets suspects dont l'application n'a pas besoin, mais qui ne sont pas supprimés par le garbage collector.

Avant de poursuivre la conversation, parlons de la façon de créer des vidages de tas. Pour résoudre ce problème, nous utiliserons le paquetage npm heapdump , qui vous permet d'obtenir par programme un vidage du tas du serveur.

Installez le package:

npm i heapdump

Nous allons apporter quelques modifications au code du serveur qui nous permettront d'utiliser ce package:

const express = require('express');
const heapdump = require("heapdump");

const app = express();
const port = 3000;

const leaks = [];

app.get('/bloatMyServer', (req, res) => {
  const redundantObj = {
    memory: "leaked",
    joke: "meta"
  };

  [...Array(10000)].map(i => leaks.push(redundantObj));

  res.status(200).send({size: leaks.length})
});

app.get('/heapdump', (req, res) => {
  heapdump.writeSnapshot(`heapDump-${Date.now()}.heapsnapshot`, (err, filename) => {
    console.log("Heap dump of a bloated server written to", filename);

    res.status(200).send({msg: "successfully took a heap dump"})
  });
});

app.listen(port, () => {
  heapdump.writeSnapshot(`heapDumpAtServerStart.heapsnapshot`, (err, filename) => {
    console.log("Heap dump of a fresh server written to", filename);
  });
});

Ici, nous avons utilisé ce package pour vider un serveur fraîchement lancé. Nous avons également créé une API /heapdumpconçue pour créer un tas lors de l'accès. Nous allons nous tourner vers cette API au moment où nous nous rendons compte que le serveur a commencé à consommer trop de mémoire.

Si votre serveur s'exécute dans un cluster Kubernetes, vous ne pourrez pas, sans effort supplémentaire, vous tourner vers ce même pod dont le serveur s'exécute et qui consomme trop de mémoire. Pour ce faire, vous pouvez utiliser la redirection de port . De plus, comme vous n'aurez pas accès au système de fichiers dont vous avez besoin pour télécharger des fichiers de vidage, il serait préférable de télécharger ces fichiers vers un stockage cloud externe (comme S3).

▍ Détection de fuite de mémoire

Et maintenant, le serveur est déployé. Il travaille depuis plusieurs jours. Il reçoit beaucoup de requêtes (dans notre cas, uniquement des requêtes du même type) et nous avons fait attention à l'augmentation de la quantité de mémoire consommée par le serveur. Une fuite de mémoire peut être détectée à l'aide d'outils de surveillance comme Express Status Monitor , Clinic , Prometheus . Après cela, nous appelons l'API pour vider le tas. Ce vidage contiendra tous les objets que le garbage collector n'a pas pu supprimer.

Voici à quoi ressemble la requête pour créer un vidage:

curl --location --request GET 'http://localhost:3000/heapdump'

Lorsqu'un vidage de tas est créé, le garbage collector est obligé de s'exécuter. Par conséquent, nous n'avons pas à nous soucier des objets qui pourraient être supprimés par le garbage collector à l'avenir, mais qui sont toujours sur le tas. C'est-à-dire sur les objets lorsque vous travaillez avec lesquels des fuites de mémoire ne se produisent pas.

Une fois que nous avons les deux vidages à notre disposition (un vidage d'un serveur fraîchement lancé et un vidage d'un serveur qui fonctionne depuis un certain temps), nous pouvons commencer à les comparer.

L'obtention d'un vidage de la mémoire est une opération de blocage qui nécessite beaucoup de mémoire. Par conséquent, il doit être effectué avec prudence. Vous pouvez en savoir plus sur les problèmes possibles rencontrés lors de cette opération ici .

Lancez Chrome et appuyez sur la touche.F12. Cela conduira à la découverte d'outils de développement. Ici, vous devez accéder à l'onglet Memoryet charger les deux instantanés de mémoire.

Le téléchargement mémoire amoncelés sur l'onglet Mémoire des outils de développement Chrome

Après avoir téléchargédeux instantanés, vous devez changerperspectivepourComparisonet cliquez sur l'instantané de la mémoire du serveur quitravaillé pendantcertain temps.

Commencer à comparer des instantanés

Ici, nous pouvons analyser la colonneConstructoret rechercher des objets que le garbage collector ne peut pas supprimer. La plupart de ces objets seront représentés par des liens internes que les nœuds utilisent. Ici, il est utile d'utiliser une astuce, qui consiste à trier la liste par champAlloc. Size. Cela trouvera rapidement les objets qui utilisent le plus de mémoire. Si vous développez le bloc(array), puis -(object elements), vous pouvez voir un tableauleakscontenant un grand nombre d'objets qui ne peuvent pas être supprimés à l'aide du garbage collector.

Analyse d'une baie suspecte

Cette technique nous permettra d'accéder à la baieleakset de comprendre que c'est l'opération incorrecte avec elle qui provoque une fuite de mémoire.

LeakFix mémoire fuite

Maintenant que nous savons que le «coupable» est un tableau leaks, nous pouvons analyser le code et découvrir que le problème est que le tableau est déclaré en dehors du gestionnaire de requêtes. En conséquence, il s'avère que le lien vers celui-ci n'est jamais supprimé. Pour résoudre ce problème est assez simple - il suffit de transférer la déclaration du tableau au gestionnaire:

app.get('/bloatMyServer', (req, res) => {
  const redundantObj = {
    memory: "leaked",
    joke: "meta"
  };

  const leaks = [];

  [...Array(10000)].map(i => leaks.push(redundantObj));

  res.status(200).send({size: leaks.length})
});

Afin de vérifier l'efficacité des mesures prises, il suffit de répéter les étapes ci-dessus et de comparer à nouveau les images de tas.

Sommaire

Les fuites de mémoire se produisent dans différentes langues. En particulier, dans - ceux qui utilisent des mécanismes de collecte des ordures. Par exemple, en JavaScript. Il n'est généralement pas difficile de réparer une fuite - les vraies difficultés ne surviennent que lorsque vous la recherchez.

Dans cet article, vous vous êtes familiarisé avec les bases de la gestion de la mémoire et la façon dont la gestion de la mémoire est organisée dans différentes langues. Ici, nous avons reproduit un scénario réel de fuite de mémoire et décrit une méthode de dépannage.

Chers lecteurs! Avez-vous rencontré des fuites de mémoire dans vos projets Web?

Un guide pratique pour gérer les fuites de mémoire dans Node.js