xvda1 è pieno al 100%, che cos'è? come risolvere?

Sto eseguendo un'istanza Linux su EC2 (ho MongoDB e node.js installati) e visualizzo questo errore:

Cannot write: No space left on device

Penso di averlo rintracciato in questo file, ecco l'output df

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

Il problema è che non so cosa sia questo file e non so nemmeno se questo file sia il problema.

Quindi la mia domanda è: come posso correggere l'errore "Nessuno spazio lasciato sul dispositivo"?

Quel file /è la tua directory principale. Se è l'unico filesystem in cui vedi df, allora è tutto. Hai un filesystem da 1 GB ed è pieno al 100%. Puoi iniziare a capire come viene usato in questo modo:

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

È quindi possibile sostituire /con i percorsi che occupano più spazio. (Saranno alla fine, grazie a sort. Il comando potrebbe richiedere del tempo.)

So che sto rispondendo in questo thread dopo quasi 5 anni, ma potrebbe aiutare qualcuno, ho avuto lo stesso problema, ho avuto m4.xlarge istanza df -h ha detto che / dev / xvda1 era pieno, - 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

ho provato a risolverlo qui sono i passaggi

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

Mi ha aiutato a sapere che era il contenitore della finestra mobile che stava parlando di tutto il mio spazio, quindi ho spinto tutti i miei contenitori nel mio registro della finestra mobile quindi ho fatto sudo rm -rf / var / lib / docker / ha liberato il mio spazio :) spero che aiuti qualcuno :)

Se si esegue un'istanza di avvio EBS (consigliata), è possibile aumentare la dimensione del volume principale (/) utilizzando la procedura descritta in questo articolo:

Ridimensionamento del disco di root su un'istanza EC2 Boot EBS in esecuzione
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Se si esegue un'istanza del negozio di istanze (non consigliata), non è possibile modificare le dimensioni del disco di root. Devi eliminare i file o spostare i file nella memoria temporanea (ad esempio, / mnt) o allegare volumi EBS e spostare i file lì.

Ecco un articolo che ho scritto che descrive come spostare un database MySQL dal disco di root su un volume EBS:

Esecuzione di MySQL su Amazon EC2 con EBS
http://aws.amazon.com/articles/1663

... e considera di passare alle istanze di avvio di EBS. Ci sono molte ragioni per cui ti ringrazierai più tardi.

Di recente ho riscontrato questo problema su Amazon Linux. La mia coda di posta elettronica in uscita crontab /var/spool/clientmqueueera di 4,5 GB.

L'ho risolto con:

1. Individuazione di file di grandi dimensioni: sudo find / -type f -size +10M -exec ls -lh {} \;
2. Eliminazione di file di grandi dimensioni: /bin/rm -f <path-to-large-file>
3. Riavvia l'istanza del server

Problema risolto!

Ho appena risolto quel problema eseguendo questo comando:

sudo apt autoremove

e molti vecchi pacchetti furono rimossi, liberando 5 gigabyte, per esempio c'erano molti pacchetti come questo "linux-aws-headers-4.4.0-1028"

Potrebbe venire da Jenkins o Docker. Per risolverlo, è necessario pulire i registri di Jenkings e impostarne le dimensioni .