web-dev-qa-db-fra.com

L'exécution de toute commande retourne "Impossible d'allouer de la mémoire" sur le serveur Ubuntu

J'utilise Ubuntu 14.04. Récemment, lorsque je me connecte via SSH avec mon utilisateur disposant des privilèges Sudo, chaque commande exécutée génère une erreur "Impossible d'allouer de la mémoire". En voici quelques unes que j'ai essayées sur ma console

myuser@mymachine:~$ whoami
-bash: fork: Cannot allocate memory
myuser@mymachine:~$ uname -a
-bash: fork: Cannot allocate memory

Même si j'essaie Sudo reboot now j'obtiens l'erreur ci-dessus, donc je ne sais pas quoi d'autre je peux essayer de déverrouiller mon instance. L'hôte est DigitalOcean si cela compte.

Edit: Selon la réponse/suggestion donnée ici, la sortie "libre"

myuser@mymachine:~$ free
-bash: fork: Cannot allocate memory
serverbashramrebootmemory-usage
9
Dave

Solution

Comme il est indiqué dans les messages d'erreur, votre ordinateur est à court de mémoire. Cela peut être dû à un certain nombre de raisons, mais fondamentalement, quelque chose grignote toute votre mémoire et ne laisse aucune trace, même pour une utilisation de base des commandes.

Je vous suggérerais de redémarrer votre droplet (allez simplement sur le panneau de configuration de votre client et sélectionnez "Redémarrer"), ssh in puis exécutez top ou htop. Surveillez l'utilisation de la mémoire et voyez quel processus utilise toute la mémoire. De là, essayez soit

  1. Tuer/supprimer le programme/processus défectueux

    WARNING: PLEASE faites votre recherche pour savoir si le processus est en cours un processus système essentiel, d'abord! Si un processus système cause des problèmes de mémoire, ne vous contentez pas de le tuer, faites des recherches dessus et recherchez des moyens spécifiques de le gérer.
  2. Changer la configuration de ce programme/processus afin qu’il ne dévale pas toute votre mémoire.

Suggestions pour éviter que le problème ne se reproduise

  • Une bonne chose à faire est de ajouter de la mémoire d'échange , car cela alloue plus de mémoire si vous êtes à court.
  • Chaque fois que vous installez des programmes, assurez-vous de les configurer correctement de manière à ce qu'ils ne fonctionnent pas de manière inattendue (par exemple, en consommant trop de mémoire).
  • Après chaque fois que vous ajoutez un package ou que quelque chose de nouveau soit configuré, vérifiez avec htop ou top pour savoir combien de mémoire vous utilisez avec les programmes actuels. Si vous remarquez que vous utilisez la quasi-totalité de ces informations, essayez d’en éliminer certains en éliminant les programmes/processus inutiles.
  • S'il y a quelque chose qui est démarré automatiquement (en plus des processus système, bien sûr!) Que vous ne reconnaissez pas ou ne souhaitez pas être démarré automatiquement, supprimez-le! Mais faites toujours votre recherche sur ce qu’est un processus avant de le supprimer/le supprimer, car il pourrait être essentiel pour les procédures de démarrage ou les fonctions système, etc.
10
Owen Hines

Pour sortir de cette situation sans redémarrer, vous pouvez déclencher le tueur de MOO manuellement de la manière suivante:

echo 1 > /proc/sys/kernel/sysrq
echo f > /proc/sysrq-trigger
echo 0 > /proc/sys/kernel/sysrq

Référence

4
Luke F

En complément de la réponse acceptée, il y a une chose supplémentaire à considérer: votre système peut manquer de descripteurs de fichier ou même tampons de sockets et avoir encore beaucoup de mémoire en même temps. Erreur. Cela est particulièrement vrai si l'hébergement partagé impose des limites de cette nature. Sur les systèmes OpenVZ, regardez le contenu de

# cat/proc/user_beancounters

Cela vous donnera les premiers dépassements dans la colonne la plus à droite. Si cela est vrai, optez pour un pack d’hébergement plus important ou pour rechercher le coupable le plus probable: la base de données mysql ou mariadb qui, en présence d’une _PHP application défectueuse, perdra le nombre de fichiers manipulés par centaines .

Cela peut également se produire si votre serveur Web a ssh ouvert sur Internet et accepte les identifiants de nom d'utilisateur/mot de passe: même si Fail2ban est en cours d'exécution, vous avez peut-être attiré une tentative de rupture de dictionnaire distribué qui consomme également beaucoup de ressources.

0
aquaherd