xvda1 está 100% lleno, ¿qué es? ¿como arreglar?

41

Estoy ejecutando una instancia de Linux en EC2 (tengo MongoDB y node.js instalados) y obtengo este error:

Cannot write: No space left on device

Creo que lo he rastreado hasta este archivo, aquí está la salida de df

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

El problema es que no sé qué es este archivo y tampoco sé si este archivo es el problema.

Entonces mi pregunta es: ¿Cómo soluciono el error "No queda espacio en el dispositivo"?

linux amazon-ec2 xen Chris Biscardi
fuente

Respuestas:

68

Ese archivo /es tu directorio raíz. Si es el único sistema de archivos que ves df, entonces es todo. Tienes un sistema de archivos de 1GB y está 100% lleno. Puedes comenzar a descubrir cómo se usa así:

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

Luego puede reemplazar /con los caminos que ocupan más espacio. (Estarán al final, gracias a sort. El comando puede tardar un tiempo).

David Schwartz
fuente
19
Para obtener la salida en un formato legible para humanos, puede usar sudo du -x -h / | sort -h | tail -40(de esta respuesta ).
mkobit
Para aquellos en instancias de AMI micro AWS, esto puede tardar un minuto más o menos en ejecutarse. ¡Se paciente!
Dr. Rob Lang
qué hacer con esto:sort: write failed: /tmp/sortGmL8oF: No space left on device
Dom
1
@dOM Ouch. Intenta limpiar un poco de espacio /tmp. O, si es necesario, acóplelo paso a paso con comandos como du -xhs /*.
David Schwartz
du -x -h / | sort -h | tail -40 | sort -h -rse puede usar para ordenar en orden descendente cuando se usa una salida legible por humanos.
Vigs
14

Sé que estoy respondiendo en este hilo después de casi 5 años, pero podría ayudar a alguien, tuve el mismo problema, tuve m4.xlarge instancia df -h me dijo que / dev / xvda1 estaba lleno, - 100%

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

Traté de resolverlo aquí están los pasos

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

Me ayudó a saber que era el contenedor de Docker el que estaba hablando todo mi espacio, así que empujé todo mi contenedor a mi registro de Docker y luego sudo rm -rf / var / lib / docker / despejó mi espacio :) espero que ayude a alguien :)

Aplastar
fuente
8

Si está ejecutando una instancia de arranque de EBS (recomendado), puede aumentar el tamaño del volumen raíz (/) utilizando el procedimiento que describo en este artículo:

Cambiar el tamaño del disco raíz en una instancia EBS Boot EC2 en ejecución
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Si está ejecutando una instancia de tienda de instancias (no recomendado), entonces no puede cambiar el tamaño del disco raíz. Tiene que eliminar archivos o mover archivos al almacenamiento efímero (por ejemplo, / mnt) o adjuntar volúmenes EBS y mover archivos allí.

Aquí hay un artículo que escribí que describe cómo mover una base de datos MySQL del disco raíz a un volumen EBS:

Ejecutar MySQL en Amazon EC2 con EBS
http://aws.amazon.com/articles/1663

... y considere pasar a las instancias de arranque de EBS. Hay muchas razones por las que te lo agradecerás más tarde.

Eric Hammond
fuente
Estoy ejecutando en EBS, es bastante barato expandir el disco raíz ¿verdad? Afortunadamente no tengo que lidiar con MySQL, mis proyectos son actualmente Mongo / Redis. Un gran material aquí. +1
2

Recientemente me he encontrado con este problema en Amazon Linux. Mi cola de correo electrónico saliente de crontab /var/spool/clientmqueueera de 4.5 GB.

Lo resolví por:

  1. Localización de archivos grandes: sudo find / -type f -size +10M -exec ls -lh {} \;
  2. Eliminar archivos grandes: /bin/rm -f <path-to-large-file>
  3. Reiniciar instancia del servidor

¡Problema resuelto!

Gabe Karkanis
fuente
1

Acabo de resolver ese problema ejecutando este comando:

sudo apt autoremove

y se eliminaron muchos paquetes antiguos, liberando 5 gigabytes, por ejemplo, había muchos paquetes como este "linux-aws-headers-4.4.0-1028"

Paulo
fuente