xvda1 est plein à 100%, c'est quoi? comment réparer?

41

J'exécute une instance Linux sur EC2 (j'ai MongoDB et node.js installés) et j'obtiens cette erreur:

Cannot write: No space left on device

Je pense que je l'ai retrouvé dans ce fichier, voici la sortie df

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/xvda1             1032088   1032088         0 100% /

Le problème est que je ne sais pas ce qu’est ce fichier et je ne sais pas non plus si ce fichier est le problème.

Ma question est donc la suivante: comment corriger l'erreur "Il ne reste plus d'espace sur le périphérique"?

linux amazon-ec2 xen Chris Biscardi
la source

Réponses:

68

Ce fichier /est votre répertoire racine. Si c'est le seul système de fichiers que vous voyez dans df, c'est tout. Vous avez un système de fichiers de 1 Go et il est plein à 100%. Vous pouvez commencer à comprendre comment il est utilisé comme ceci:

sudo du -x / | sort -n | tail -40

Vous pouvez ensuite remplacer /par les chemins qui occupent le plus d'espace. (Ils seront à la fin, grâce au sort. La commande peut prendre un certain temps.)

David Schwartz
la source
19
Pour obtenir la sortie dans un format lisible par l'homme, vous pouvez utiliser sudo du -x -h / | sort -h | tail -40(à partir de cette réponse ).
mkobit
Pour les utilisateurs d'instances AMI micro AWS, l'exécution peut prendre environ une minute. Sois patient!
Dr Rob Lang
quoi faire avec ceci:sort: write failed: /tmp/sortGmL8oF: No space left on device
dOM
1
@ dOM Ouch. Essayez de nettoyer de l'espace sur /tmp. Ou, si vous devez, réduisez-le pas à pas avec des commandes telles que du -xhs /*.
David Schwartz
du -x -h / | sort -h | tail -40 | sort -h -rpeut être utilisé pour trier par ordre décroissant lorsqu’on utilise une sortie lisible par l’homme.
Vigs
14

Je sais que je réponds dans ce fil de discussion au bout de presque 5 ans, mais cela pourrait aider quelqu'un. J'avais le même problème.

Filesystem      Size  Used Avail Use% Mounted on
udev            7.9G     0  7.9G   0% /dev
tmpfs           1.6G  177M  1.4G  12% /run
/dev/xvda1      7.7G  7.7G     0 100% /
tmpfs           7.9G     0  7.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           7.9G     0  7.9G   0% /sys/fs/cgroup
tmpfs           1.6G     0  1.6G   0% /run/user/1000

j'ai essayé de le résoudre ici sont les étapes

sudo find / -type f -printf '%12s %p\n' 2>/dev/null|awk '{if($1>999999999)print $0;}'

M'a aidé à savoir que c'était le conteneur docker qui parlait de tout mon espace; j'ai donc poussé tout mon conteneur dans mon registre docker, puis sudo a fait rm -rf / var / lib / docker / il a éclairci mon espace :) j'espère que cela aide quelqu'un :)

Écraser
la source
8

Si vous exécutez une instance de démarrage EBS (recommandé), vous pouvez augmenter la taille du volume racine (/) à l'aide de la procédure décrite dans cet article:

Redimensionnement du disque racine sur une instance EBS Boot EC2 en cours d'exécution
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Si vous exécutez une instance de stockage d'instance (non recommandé), vous ne pouvez pas modifier la taille du disque racine. Vous devez soit supprimer des fichiers, soit déplacer des fichiers vers un stockage éphémère (par exemple, / mnt) ou joindre des volumes EBS et y déplacer des fichiers.

Voici un article que j'ai écrit et qui explique comment déplacer une base de données MySQL du disque racine vers un volume EBS:

Exécution de MySQL sur Amazon EC2 avec EBS
http://aws.amazon.com/articles/1663

... et envisagez de passer aux instances de démarrage EBS. Il y a plusieurs raisons pour lesquelles vous vous remercierez plus tard.

Eric Hammond
la source
Je cours sur EBS, il est assez bon marché d’étendre le disque racine, non? Heureusement, je n'ai pas à traiter avec MySQL, mes projets sont actuellement Mongo / Redis. du bon matériel ici. +1
2

J'ai récemment rencontré ce problème sur Amazon Linux. Ma file d'attente de messagerie sortante crontab /var/spool/clientmqueuefaisait 4,5 Go.

Je l'ai résolu par:

  1. Localisation de gros fichiers: sudo find / -type f -size +10M -exec ls -lh {} \;
  2. Suppression de gros fichiers: /bin/rm -f <path-to-large-file>
  3. Redémarrer l'instance du serveur

Problème résolu!

Gabe Karkanis
la source
1

Je viens de résoudre ce problème en exécutant cette commande:

sudo apt autoremove

et beaucoup de vieux paquets ont été supprimés, libérant 5 gigaoctets. Par exemple, il y avait beaucoup de paquets comme celui-ci "linux-aws-headers-4.4.0-1028"

Paulo
la source