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

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"?

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.)

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 :)

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.

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!

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"

Cela pourrait venir de Jenkins ou de Docker. Pour résoudre ce problème, vous devez nettoyer les journaux Jenkings et définir sa taille .