Comment résoudre les problèmes d'une instance Linux EC2 qui échoue à une surveillance de l’état en raison d'une surutilisation des ressources ?

Brève description

La vérification de l'état de votre instance risque d'échouer en raison de l'utilisation des ressources pour les raisons suivantes :

• L'utilisation du processeur de votre instance atteint près de 100 % et la capacité de calcul restante de l'instance était insuffisante pour permettre au noyau de fonctionner.
• Le périphérique racine est complètement saturé et ne permet pas aux autres processus de se terminer ou de démarrer.
• Les processus qui s'exécutent sur l'instance ont utilisé toute sa mémoire et n'autorisent pas l'exécution du noyau.

Résolution

Important : Avant d'arrêter et de démarrer votre instance, effectuez les actions suivantes.

• Créez un instantané de votre volume Amazon Elastic Block Store (Amazon EBS).
  Remarque : Si votre instance est sauvegardée par un stockage d'instances ou si ses volumes de stockage d'instances contiennent des données, Amazon EC2 supprime les données lorsque vous arrêtez l'instance.
• Supprimez temporairement l'instance de son groupe Amazon EC2 Auto Scaling.
  Remarque : Si vous arrêtez une instance qui se trouve dans un groupe Auto Scaling Amazon EC2, vous pouvez la résilier en fonction de vos paramètres de protection de réduction horizontale. Les instances que vous lancez avec Amazon EMR, AWS CloudFormation ou AWS Elastic Beanstalk peuvent faire partie d'un groupe Auto Scaling.
• Définissez le comportement d'arrêt de l'instance** sur **Arrêter pour vous assurer que les instances ne se résilient pas lorsque vous les arrêtez.

Arrêtez et démarrez votre instance pour forcer le noyau à arrêter les processus en cours d'exécution. Il s'agit d'une solution temporaire permettant de restituer des ressources au système d'exploitation (SE). Pour résoudre les problèmes de surutilisation, effectuez les actions suivantes pour traiter la cause racine.

Remarque : Lorsque vous arrêtez et démarrez une instance, son adresse IP publique change. Une bonne pratique consiste à utiliser une adresse IP Elastic pour acheminer le trafic externe vers votre instance au lieu d'une adresse IP publique.

Vérifier les métriques du processeur CloudWatch de l'instance

Vérifiez si la métrique d'utilisation du processeur Amazon CloudWatch de l'instance est égale ou proche de 100 %. Si tel est le cas, redémarrez votre instance pour rétablir l’état sain de l’instance. Si le problème persiste après le redémarrage, les exigences relatives au processeur de l'instance sont supérieures à celles proposées par votre type d'instance.

Pour résoudre ce problème, remplacez votre type d’instance par une instance offrant une disponibilité de processeur plus élevée.

Si votre instance est une instance aux performances éclatantes, telle que T2, T3 ou T3a, vérifiez sa métrique CPUCreditBalance. Si le solde créditeur est proche de zéro, Amazon EC2 limite le processeur de l'instance. Si vous définissez la spécification de crédit de l'instance sur Standard, modifiez-la à Illimité.

Vérifier que le journal système de l’instance ne contient pas d’erreurs

Consultez le journal système pour détecter d’éventuelles erreurs telles que « No space left on device » ou « Out of memory ».

Résoudre l'erreur « No space left on device »

Si le système de fichiers contenant un dossier répertorié est saturé, une erreur similaire à l'exemple suivant s'affiche :

« OSError: [Error 28] No space left on device '/var/lib/' »

Dans l'exemple précédent, /var/lib est saturé.

Pour libérer de l'espace, utilisez l’EC2 Serial Console pour vous connecter aux types d'instances basées sur Nitro pris en charge et aux instances de matériel nu prises en charge. Puis, supprimez les fichiers inutiles. Lorsque vous utilisez l'EC2 Serial Console, vous n'avez pas besoin d'une connexion fonctionnelle pour vous connecter à votre instance.

Si vous n'avez jamais utilisé l’EC2 Serial Console auparavant, assurez-vous de respecter les prérequis. Si votre instance est inaccessible et que vous n'avez pas encore configuré l'accès à la console série, vous ne pouvez pas utiliser l’EC2 Serial Console.

Si vous ne pouvez pas utiliser l’EC2 Serial Console, procédez comme suit pour lancer une instance de secours et supprimer les fichiers inutiles :

1. Lancez une nouvelle instance de secours EC2 dans votre cloud privé virtuel (VPC). Utilisez la même Amazon Machine Image (AMI) et la même zone de disponibilité que l'instance dont la surveillance de l’état a échoué.
   Remarque : Vous pouvez également utiliser une instance existante qui se trouve dans la même zone de disponibilité et utilise la même AMI que l'instance d'origine.

2. Démarrez l'instance d'origine.

3. Détachez le volume racine Amazon Elastic Block Store (Amazon EBS), tel que /dev/xvda ou /dev/sda1, de l'instance d'origine. Notez le nom de périphérique de votre volume racine.

4. Attachez le volume en tant que périphérique secondaire /dev/sdf à l'instance de secours.

5. Utilisez SSH pour vous connecter à votre instance de secours.

6. Pour créer un répertoire de points de montage pour le volume que vous avez attaché à l’instance de secours, exécutez la commande suivante :

   sudo mkdir /rescue

   Remarque : Remplacez /rescue par le nom du répertoire de votre point de montage.

7. En tant qu'utilisateur racine, exécutez la commande suivante pour identifier le nom de périphérique correct :

   sudo -i
   # lsblk

   Remarque : Le périphérique attaché à l'instance de secours peut avoir un nom de périphérique différent.

8. Pour monter le volume dans le nouveau répertoire, exécutez la commande suivante :

   sudo mount /dev/xvdf1 /rescue

   Remarque : Remplacez dev/xvdf1 par le nom du périphérique de votre volume racine et /rescue par le nom du répertoire de votre point de montage. Si vous recevez un message d'erreur lorsque vous exécutez la commande précédente, consultez la section Pourquoi ne puis-je pas monter mon volume Amazon EBS ?

9. Pour identifier les fichiers qui occupent le plus d'espace, exécutez la commande suivante :

   du -shcm /rescue/var/lib/* |sort -n

10. Pour libérer de l'espace, supprimez les fichiers volumineux dont vous n'avez pas besoin.

11. Pour démonter le périphérique secondaire sur votre instance de secours, exécutez la commande suivante :

sudo umount /rescue

Remarque : Remplacez /rescue par le nom du répertoire de votre point de montage.
Si l'opération de démontage échoue, arrêtez ou redémarrez l'instance de secours. Puis, réexécutez la commande précédente. Détachez le volume secondaire de l'instance de secours. Attachez le volume racine à l'instance d'origine en tant que volume racine /dev/xvda ou /dev/sda1. Démarrez l'instance, puis vérifiez qu’elle est réactive.

Si vous ne disposez toujours pas d'un espace de stockage suffisant, procédez comme suit pour redimensionner le volume EBS racine :

1. Demandez une modification de la taille du volume EBS.
2. Suivez les étapes 1 à 8 de la section précédente pour lancer une instance de secours.
3. Étendez le système de fichiers Linux.

Résoudre l'erreur « Out of memory »

Si la mémoire de votre instance est insuffisante, le message d'erreur suivant s'affiche :

« Out of memory: kill process »

Lorsque la mémoire de l'instance est insuffisante, le noyau ne dispose pas d’une quantité de mémoire suffisante pour s'exécuter et Amazon EC2 met fin aux autres processus pour libérer de la mémoire. Pour les étapes de résolution de problèmes, consultez la section Out of memory: kill process.

Pour vérifier vos journaux de mémoire, suivez les étapes 1 à 8 de la section précédente pour lancer une instance de secours. Puis, exécutez la commande suivante en fonction de votre distribution Linux pour rechercher les messages « out of memory » dans les journaux :

Amazon Linux 2 (AL2) :

sudo grep -i -r 'out of memory' /var/log/

Amazon Linux 2023 (AL2023) :

sudo journalctl -p err | grep -i "out of memory"

-ou-

sudo dmesg | grep -i "out of memory"

Résoudre les problèmes d'allocation de pages

L'erreur « page allocation failure » se produit lorsque l'allocateur de mémoire du noyau ne répond pas à la demande d'allocation.

Pour résoudre ce problème, il est recommandé de mettre à niveau l'instance vers un type d'instance plus important. Ou, pour les instances qui utilisent des volumes de stockage d'instance éphémères, utilisez un fichier d'échange ou une partition de disque dur pour ajouter un stockage d'échange à l'instance et atténuer la pression sur la mémoire.

Remarque : L'instance utilise l'espace d’échange lorsque la RAM est saturée. Vous pouvez utiliser l'espace d'échange pour les instances disposant d'une petite quantité de RAM. Cependant, l'espace d'échange ne remplace pas une plus grande quantité de RAM. Étant donné que l'espace d'échange se trouve sur le disque dur de l'instance, les performances sont plus lentes que celles de la RAM. Pour augmenter ou accélérer la quantité de mémoire, vous devez augmenter la taille de l'instance.

Utiliser atop pour étudier et prévenir les problèmes de ressources

Utilisez l'outil de surveillance atop pour identifier les modèles d'utilisation des ressources et les processus susceptibles de provoquer des problèmes avant qu'ils n’entraînent des échecs du système. L'outil atop vous aide à surveiller et à dépanner le système en permanence.

Remarque : L'outil atop journalise les données uniquement après son installation. Vous ne pouvez pas récupérer les données de performance historiques antérieures à l'installation de l'outil atop.

Utilisez l'outil top pour vérifier les ressources suivantes :

• Consultez les données historiques dans /var/log/atop/ pour analyser votre système et vos processus lorsque l’échec s'est produit.
• Recherchez les processus qui consomment une grande quantité de ressources.
• Vérifiez les modèles d'utilisation de la mémoire, du processeur et du disque à l'origine de l’échec.

Informations connexes

Comment résoudre les problèmes liés à la surveillance de l'état de mon instance Linux EC2 ?

Quelles étapes dois-je suivre avant de changer le type d'instance de mon instance Linux EC2 ?