Node.js: gestion de la mémoire disponible pour les applications s'exécutant dans des conteneurs

Lors de l'exécution d'applications Node.js dans des conteneurs Docker, les paramètres de mémoire traditionnels ne fonctionnent pas toujours comme prévu. Le matériel, dont nous publions la traduction aujourd'hui, est consacré à trouver la réponse à la question de savoir pourquoi. Il fournira également des recommandations pratiques pour gérer la mémoire disponible pour les applications Node.js s'exécutant dans des conteneurs.

Examen des recommandations

Supposons qu'une application Node.js s'exécute dans un conteneur avec une limite de mémoire définie. Si nous parlons de Docker, l'option --memory pourrait être utilisée pour définir cette limite. Quelque chose de similaire est possible lorsque vous travaillez avec des systèmes d'orchestration de conteneurs. Dans ce cas, il est recommandé d'utiliser l' --max-old-space-size lors du démarrage de l'application Node.js. Cela vous permet d'informer la plate-forme de la quantité de mémoire dont elle dispose et de prendre également en compte le fait que cette quantité doit être inférieure à la limite définie au niveau du conteneur.

Lorsque l'application Node.js s'exécute à l'intérieur du conteneur, définissez la capacité de la mémoire disponible en fonction de la valeur maximale d'utilisation de la mémoire active par l'application. Cela se fait si les limites de mémoire du conteneur peuvent être configurées.

Parlons maintenant plus en détail du problème de l'utilisation de la mémoire dans les conteneurs.

Docker Memory Limit

Par défaut, les conteneurs n'ont pas de limites de ressources et peuvent utiliser autant de mémoire que le permet le système d'exploitation. La commande docker run dispose d'options de ligne de commande qui vous permettent de définir des limites concernant l'utilisation de la mémoire ou les ressources du processeur.

La commande de lancement de conteneur peut ressembler à ceci:

 docker run --memory <x><y> --interactive --tty <imagename> bash 

Veuillez noter ce qui suit:

• x est la limite de la quantité de mémoire disponible pour le conteneur, exprimée en unités de y .
• y peut prendre la valeur b (octets), k (kilo-octets), m (mégaoctets), g (gigaoctets).

Voici un exemple de commande de lancement de conteneur:

 docker run --memory 1000000b --interactive --tty <imagename> bash 

Ici, la limite de mémoire est fixée à 1000000 octets.

Pour vérifier la limite de mémoire définie au niveau du conteneur, vous pouvez, dans le conteneur, exécuter la commande suivante:

 cat /sys/fs/cgroup/memory/memory.limit_in_bytes 

Parlons du comportement du système lors de la spécification de la limite de mémoire de l'application Node.js à l'aide de la --max-old-space-size . Dans ce cas, cette limite de mémoire correspondra à la limite définie au niveau du conteneur.

Ce qui est appelé "ancien espace" dans le nom de la clé est l'un des fragments du tas contrôlé par V8 (l'endroit où les "anciens" objets JavaScript sont placés). Cette clé, si vous n'entrez pas dans les détails que nous touchons ci-dessous, contrôle la taille maximale du tas. Les détails sur les commutateurs de ligne de commande Node.js peuvent être trouvés ici .

En général, lorsqu'une application essaie d'utiliser plus de mémoire que celle disponible dans le conteneur, son opération se termine.

Dans l'exemple suivant (le fichier d'application est appelé test-fatal-error.js ), les objets MyRecord sont placés dans le tableau de list , avec un intervalle de 10 millisecondes. Cela conduit à une croissance incontrôlée du tas, simulant une fuite de mémoire.

 'use strict'; const list = []; setInterval(()=> { const record = new MyRecord(); list.push(record); },10); function MyRecord() { var x='hii'; this.name = x.repeat(10000000); this.id = x.repeat(10000000); this.account = x.repeat(10000000); } setInterval(()=> { console.log(process.memoryUsage()) },100); 

Veuillez noter que tous les exemples de programmes dont nous allons discuter ici sont placés dans l'image Docker, qui peut être téléchargée à partir du Docker Hub:

 docker pull ravali1906/dockermemory 

Vous pouvez utiliser cette image pour des expériences indépendantes.

De plus, vous pouvez emballer l'application dans un conteneur Docker, collecter l'image et l'exécuter avec la limite de mémoire:

 docker run --memory 512m --interactive --tty ravali1906/dockermemory bash 

Ici ravali1906/dockermemory est le nom de l'image.

Vous pouvez maintenant démarrer l'application en spécifiant une limite de mémoire qui dépasse la limite de conteneur:

 $ node --max_old_space_size=1024 test-fatal-error.js { rss: 550498304, heapTotal: 1090719744, heapUsed: 1030627104, external: 8272 } Killed 

Ici, le --max_old_space_size représente la limite de mémoire indiquée en mégaoctets. La méthode process.memoryUsage() donne des informations sur l'utilisation de la mémoire. Les valeurs sont exprimées en octets.

À un certain moment, l'application est abandonnée de force. Cela se produit lorsque la quantité de mémoire utilisée par lui franchit une certaine frontière. Quelle est cette frontière? De quelles limitations sur la quantité de mémoire peut-on parler?

Le comportement attendu d'une application exécutée avec la clé est - max-old-space-size

Par défaut, la taille de segment de mémoire maximale dans Node.js (jusqu'à la version 11.x) est de 700 Mo sur les plates-formes 32 bits et de 1400 Mo sur les plates-formes 64 bits. Vous pouvez en savoir plus sur la définition de ces valeurs ici .

En théorie, si vous utilisez la --max-old-space-size pour --max-old-space-size limite de mémoire qui dépasse la limite de mémoire du conteneur, vous pouvez vous attendre à ce que l'application soit arrêtée par le mécanisme de sécurité du noyau du noyau Linux OOM Killer.

En réalité, cela peut ne pas arriver.

Le comportement réel de l'application exécutée avec la clé est max-old-space-size

L'application, immédiatement après le lancement, n'alloue pas toute la mémoire dont la limite est spécifiée à l'aide de --max-old-space-size . La taille du tas JavaScript dépend des besoins de l'application. Vous pouvez déterminer la quantité de mémoire utilisée par l'application en fonction de la valeur du champ heapUsed de l'objet renvoyé par la méthode process.memoryUsage() . En fait, nous parlons de la mémoire allouée dans le tas pour les objets.

Par conséquent, nous concluons que l'application sera --memory force si la taille du --memory est supérieure à la limite définie par la clé --memory démarrage du conteneur.

Mais en réalité, cela peut ne pas se produire non plus.

Lors du profilage des applications Node.js gourmandes en ressources qui s'exécutent dans des conteneurs avec une limite de mémoire donnée, les modèles suivants peuvent être observés:

1. OOM Killer est déclenché bien plus tard que le moment où les heapUsed heapTotal et heapUsed sont nettement supérieures aux limites de la mémoire.
2. OOM Killer ne répond pas au dépassement des limites.

Une explication du comportement des applications Node.js dans les conteneurs

Un conteneur supervise un indicateur important des applications qui s'exécutent dessus. Il s'agit de RSS (taille de l'ensemble résident). Cet indicateur représente une certaine partie de la mémoire virtuelle de l'application.

De plus, c'est un morceau de mémoire qui est alloué à l'application.

Mais ce n'est pas tout. RSS fait partie de la mémoire active allouée à l'application.

Toute la mémoire allouée à une application peut ne pas être active. Le fait est que la «mémoire allouée» n'est pas nécessairement allouée physiquement jusqu'à ce que le processus commence à vraiment l'utiliser. De plus, en réponse aux demandes d'allocation de mémoire provenant d'autres processus, le système d'exploitation peut vider des parties inactives de la mémoire d'application dans le fichier d'échange et transférer l'espace libéré vers d'autres processus. Et lorsque l'application aura à nouveau besoin de ces morceaux de mémoire, ils seront extraits du fichier d'échange et retournés à la mémoire physique.

La métrique RSS indique la quantité de mémoire active et disponible pour l'application dans son espace d'adressage. C'est lui qui influence la décision sur l'arrêt forcé de l'application.

Preuve

▍ Exemple n ° 1. Une application qui alloue de la mémoire pour un tampon

L'exemple suivant, buffer_example.js , montre un programme qui alloue de la mémoire pour un tampon:

 const buf = Buffer.alloc(+process.argv[2] * 1024 * 1024) console.log(Math.round(buf.length / (1024 * 1024))) console.log(Math.round(process.memoryUsage().rss / (1024 * 1024))) 

Pour que la quantité de mémoire allouée par le programme dépasse la limite définie lors du lancement du conteneur, exécutez d'abord le conteneur avec la commande suivante:

 docker run --memory 1024m --interactive --tty ravali1906/dockermemory bash 

Après cela, exécutez le programme:

 $ node buffer_example 2000 2000 16 

Comme vous pouvez le voir, le système n'a pas terminé le programme, bien que la mémoire allouée par le programme dépasse la limite de conteneur. Cela est dû au fait que le programme ne fonctionne pas avec toute la mémoire allouée. RSS est très petit, il ne dépasse pas la limite de mémoire du conteneur.

▍ Exemple n ° 2. Application remplissant le tampon avec des données

Dans l'exemple suivant, buffer_example_fill.js , la mémoire n'est pas seulement allouée, mais également remplie de données:

 const buf = Buffer.alloc(+process.argv[2] * 1024 * 1024,'x') console.log(Math.round(buf.length / (1024 * 1024))) console.log(Math.round(process.memoryUsage().rss / (1024 * 1024))) 

Exécutez le conteneur:

 docker run --memory 1024m --interactive --tty ravali1906/dockermemory bash 

Après cela, exécutez l'application:

 $ node buffer_example_fill.js 2000 2000 984 

Apparemment, même maintenant, l'application ne se termine pas! Pourquoi? Le fait est que lorsque la quantité de mémoire active atteint la limite définie au démarrage du conteneur et qu'il y a de la place dans le fichier d'échange, certaines des anciennes pages de la mémoire de processus sont déplacées vers le fichier d'échange. La mémoire libérée est mise à la disposition du même processus. Par défaut, Docker alloue un espace pour le fichier d'échange égal à la limite de mémoire définie à l'aide de l'indicateur --memory . Compte tenu de cela, nous pouvons dire que le processus a 2 Go de mémoire - 1 Go dans la mémoire active et 1 Go dans le fichier d'échange. En effet, du fait que l'application peut utiliser sa propre mémoire, dont le contenu est temporairement déplacé vers le fichier d'échange, la taille de l'index RSS est dans la limite du conteneur. Par conséquent, l'application continue de fonctionner.

▍ Exemple n ° 3. Une application qui remplit un tampon avec des données s'exécutant dans un conteneur qui n'utilise pas de fichier d'échange

Voici le code que nous allons expérimenter ici (c'est le même fichier buffer_example_fill.js ):

 const buf = Buffer.alloc(+process.argv[2] * 1024 * 1024,'x') console.log(Math.round(buf.length / (1024 * 1024))) console.log(Math.round(process.memoryUsage().rss / (1024 * 1024))) 

Cette fois, exécutez le conteneur, en configurant explicitement les fonctionnalités de travail avec le fichier d'échange:

 docker run --memory 1024m --memory-swap=1024m --memory-swappiness=0 --interactive --tty ravali1906/dockermemory bash 

Lancez l'application:

 $ node buffer_example_fill.js 2000 Killed 

Voir le message Killed ? Lorsque la valeur de la clé --memory-swap est égale à la --memory clé --memory , cela indique au conteneur qu'il ne doit pas utiliser le fichier d' --memory-swap . De plus, par défaut, le noyau du système d'exploitation dans lequel s'exécute le conteneur lui-même peut vider une certaine quantité de pages mémoire anonymes utilisées par le conteneur dans le fichier d'échange. --memory-swappiness sur 0 , nous désactivons cette fonctionnalité. Par conséquent, il s'avère que le fichier d'échange n'est pas utilisé à l'intérieur du conteneur. Le processus se termine lorsque la métrique RSS dépasse la limite de mémoire du conteneur.

Recommandations générales

Lorsque les applications Node.js sont lancées avec la --max-old-space-size , dont la valeur dépasse la limite de mémoire définie au démarrage du conteneur, il peut sembler que Node.js «ne fait pas attention» à la limite du conteneur. Mais, comme le montrent les exemples précédents, la raison évidente de ce comportement est le fait que l'application n'utilise tout simplement pas le volume de --max-old-space-size entier spécifié avec l' --max-old-space-size .

N'oubliez pas que l'application ne se comportera pas toujours de la même façon si elle utilise plus de mémoire que celle disponible dans le conteneur. Pourquoi? Le fait est que la mémoire active (RSS) du processus est influencée par de nombreux facteurs externes que l’application elle-même ne peut pas influencer. Ils dépendent de la charge du système et des caractéristiques de l'environnement. Par exemple, il s'agit des fonctionnalités de l'application elle-même, du niveau de parallélisme dans le système, des fonctionnalités du planificateur du système d'exploitation, des fonctionnalités du garbage collector, etc. De plus, ces facteurs, d'un lancement à l'autre, peuvent changer.

Recommandations sur la définition de la taille du segment Node.js pour les cas où vous pouvez contrôler cette option, mais pas avec des restrictions de mémoire au niveau du conteneur

• Exécutez l'application Node.js minimale dans le conteneur et mesurez la taille RSS statique (dans mon cas, pour Node.js 10.x, cela représente environ 20 Mo).
• Le tas Node.js contient non seulement l'ancien_espace, mais également d'autres (tels que nouvel_espace, espace_code, etc.). Par conséquent, si vous prenez en compte la configuration standard de la plate-forme, vous devez vous fier au fait que le programme aura besoin d'environ 20 Mo de mémoire supplémentaire. Si les paramètres standard ont changé, ces changements doivent également être pris en compte.
• Maintenant, nous devons soustraire la valeur obtenue (supposons qu'elle sera de 40 Mo) de la quantité de mémoire disponible dans le conteneur. Ce qui reste est une valeur qui, sans crainte que l' --max-old-space-size du programme ne manque de mémoire, peut être spécifiée comme valeur clé - --max-old-space-size .

Recommandations pour la définition de limites de mémoire de conteneur pour les cas où ce paramètre peut être contrôlé, mais les paramètres d'application Node.js ne sont pas

• Exécutez l'application dans des modes qui vous permettent de connaître les valeurs maximales de la mémoire consommée par celle-ci.
• Analysez le score RSS. En particulier, ici, avec la méthode process.memoryUsage() , la commande Linux top peut être utile.
• Pourvu que dans le conteneur dans lequel il est prévu d'exécuter l'application, rien ne soit exécuté, la valeur obtenue peut être utilisée comme limite de mémoire du conteneur. Pour être sûr, il est recommandé de l'augmenter d'au moins 10%.

Résumé

Dans Node.js 12.x, certains des problèmes abordés ici sont résolus en ajustant de manière adaptative la taille du tas, qui est effectuée en fonction de la quantité de RAM disponible. Ce mécanisme fonctionne également lors de l'exécution d'applications Node.js dans des conteneurs. Mais les paramètres peuvent différer des paramètres par défaut. Cela se produit, par exemple, lorsque la clé --max_old_space_size été utilisée lors du démarrage de l'application. Pour de tels cas, tout ce qui précède reste pertinent. Cela suggère que toute personne qui exécute des applications Node.js dans des conteneurs doit être prudente et responsable concernant les paramètres de mémoire. De plus, la connaissance des limites standard d'utilisation de la mémoire, qui est plutôt conservatrice, peut améliorer les performances des applications en modifiant délibérément ces limites.

Chers lecteurs! Avez-vous manqué de problèmes de mémoire lors de l'exécution des applications Node.js dans des conteneurs Docker?