Comment définir une limite de mémoire pour les conteneurs Docker

Conteneurs Docker s’exécute par défaut sans toute contrainte de ressources. Les processus exécutés dans des conteneurs sont libres d’utiliser des quantités illimitées de mémoire, ce qui a un impact potentiel sur les conteneurs voisins et d’autres charges de travail sur votre hôte.

Ceci est dangereux dans les environnements de production. Chaque conteneur doit être configuré avec une limite de mémoire appropriée pour éviter la consommation excessive de ressources. Cela aide à réduire les conflits, ce qui maximisera la stabilité globale du système.

Fonctionnement des limites de mémoire Docker

Docker vous permet de définir des limites de mémoire matérielles et logicielles sur des conteneurs individuels. Ceux-ci ont des effets différents sur la quantité de mémoire disponible et le comportement lorsque la limite est atteinte.

• Limites de mémoire matérielle définir un plafond absolu sur la mémoire fournie au conteneur. Le dépassement de cette limite entraînera normalement l’arrêt du processus de conteneur par le tueur de mémoire insuffisante du noyau.
• Limites de mémoire logicielles indiquent la quantité de mémoire qu’un conteneur est censé utiliser. Le conteneur est autorisé à utiliser plus de mémoire lorsque la capacité est disponible. Il peut être interrompu s’il dépasse une limite souple pendant une condition de mémoire insuffisante.

Docker fournit également des contrôles pour définir les contraintes de mémoire d’échange et modifier ce qui se passe lorsqu’une limite de mémoire est atteinte. Vous verrez comment les utiliser dans les sections suivantes.

Définition des limites matérielles et logicielles de la mémoire

Une limite de mémoire matérielle est définie par le docker run commande -m ou --memory drapeau. Il prend une valeur telle que 512m (pour les mégaoctets) ou 2g (pour gigaoctets):

$ docker run --memory=512m my-app:latest

Les conteneurs ont une mémoire minimale requise de 6 Mo. Essayer d’utiliser --memory valeurs inférieures à 6m provoquera une erreur.

Les limites de mémoire logicielle sont définies avec le --memory-reservation drapeau. Cette valeur doit être inférieure à --memory. La limite ne sera appliquée qu’en cas de conflit de ressources de conteneur ou si la mémoire physique de l’hôte est faible.

$ docker run --memory=512m --memory-reservation=256m my-app:latest

Cet exemple démarre un conteneur qui dispose de 256 Mo de mémoire réservée. Le processus peut être interrompu s’il utilise 300 Mo et que la capacité est épuisée. Il s’arrêtera toujours si l’utilisation dépasse 512 Mo.

Gestion de la mémoire d’échange

Les conteneurs peuvent se voir allouer de la mémoire d’échange pour s’adapter à une utilisation élevée sans affecter la consommation de mémoire physique. Swap permet d’écrire le contenu de la mémoire sur le disque une fois que la RAM disponible a été épuisée.

La --memory-swap flag contrôle la quantité d’espace d’échange disponible. Il ne fonctionne qu’en conjonction avec --memory. Lorsque vous définissez --memory et --memory-swap à des valeurs différentes, la valeur d’échange contrôle la quantité totale de mémoire disponible pour le conteneur, y compris l’espace d’échange. La valeur de --memory détermine la partie de la quantité de mémoire physique.

$ docker run --memory=512m --memory-swap=762m my-app:latest

Ce conteneur a accès à 762 Mo de mémoire dont 512 Mo de RAM physique. Les 250 Mo restants correspondent à l’espace d’échange stocké sur le disque.

Paramètre --memory sans pour autant --memory-swap donne au conteneur l’accès à la même quantité d’espace d’échange que la mémoire physique :

$ docker run --memory=512m my-app:latest

Ce conteneur dispose d’un total de 1024 Mo de mémoire, comprenant 512 Mo de RAM et 512 Mo de swap.

L’échange peut être désactivé pour un conteneur en définissant le paramètre --memory-swap drapeau à la même valeur que --memory. Comme --memory-swap définit la quantité totale de mémoire, et --memory alloue la proportion de mémoire physique, vous indiquez à Docker que 100 % de la mémoire disponible doit être de la RAM.

Dans tous les cas, le swap ne fonctionne que lorsqu’il est activé sur votre hébergeur. Les rapports d’échange à l’intérieur des conteneurs ne sont pas fiables et ne doivent pas être utilisés. Des commandes telles que free qui sont exécutés dans un conteneur afficheront la quantité totale d’espace d’échange sur votre hôte Docker, et non l’espace d’échange accessible au conteneur.

Désactivation des éliminations de processus hors mémoire

Les erreurs de mémoire insuffisante dans un conteneur provoquent normalement l’arrêt du processus par le noyau. Cela entraîne l’arrêt du conteneur avec le code de sortie 137.

Y compris le drapeau facultatif --oom-kill-disable avec votre docker run La commande désactive ce comportement. Au lieu d’arrêter le processus, le noyau bloquera simplement les nouvelles allocations de mémoire. Le processus semblera se bloquer jusqu’à ce que vous réduisiez son utilisation de la mémoire, annuliez les nouvelles allocations de mémoire ou redémarriez manuellement le conteneur.

Cet indicateur ne doit pas être utilisé à moins que vous n’ayez implémenté vous-même des mécanismes pour résoudre les problèmes de mémoire insuffisante. Il est généralement préférable de laisser le noyau tuer le processus, provoquant un redémarrage du conteneur qui restaure la consommation normale de mémoire.

Sommaire

Les conteneurs Docker sont livrés sans contraintes de ressources pré-appliquées. Cela laisse les processus de conteneur libres de consommer de la mémoire illimitée, menaçant la stabilité de votre hôte.

Dans cet article, vous avez appris à définir des limites matérielles et logicielles de mémoire pour les conteneurs afin de réduire les risques de manque de mémoire. La définition de ces limites sur tous vos conteneurs réduira les conflits de ressources et vous aidera à respecter la capacité de mémoire physique de votre hôte. Vous devriez considérer utilisation des limites du processeur aux côtés de vos plafonds de mémoire – ceux-ci empêcheront les conteneurs individuels avec une forte demande de CPU d’avoir un impact néfaste sur leurs voisins.