xvda1 ist 100% voll, was ist das? wie repariert man?

41

Ich führe eine Linux-Instanz auf EC2 aus (ich habe MongoDB und node.js installiert) und bekomme den folgenden Fehler:

Cannot write: No space left on device

Ich denke, ich habe es bis zu dieser Datei aufgespürt, hier ist die df-Ausgabe

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

Das Problem ist, ich weiß nicht, was diese Datei ist und ich weiß auch nicht, ob diese Datei überhaupt das Problem ist.

Meine Frage lautet also: Wie behebe ich den Fehler "Kein Platz mehr auf dem Gerät"?

linux amazon-ec2 xen Chris Biscardi
quelle

Antworten:

66

Diese Datei /ist Ihr Stammverzeichnis. Wenn es das einzige Dateisystem ist, in dem Sie es sehen df, dann ist es alles. Sie haben ein Dateisystem von 1 GB und es ist zu 100% voll. Sie können anfangen herauszufinden, wie es so verwendet wird:

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

Sie können dann durch /die Pfade ersetzen , die am meisten Platz beanspruchen. (Dank der werden sie am Ende sein sort. Der Befehl kann eine Weile dauern.)

David Schwartz
quelle
19
Um die Ausgabe in einem für Menschen lesbaren Format zu erhalten, können Sie sudo du -x -h / | sort -h | tail -40(aus dieser Antwort ) verwenden.
mkobit
Für Benutzer von Micro-AWS-AMI-Instanzen kann dies ungefähr eine Minute dauern. Sei geduldig!
Dr. Rob Lang
was damit zu tun ist:sort: write failed: /tmp/sortGmL8oF: No space left on device
dOM
1
@dOM Autsch. Versuchen Sie, etwas Platz wegzuräumen /tmp. Oder, wenn Sie müssen, schränken Sie es Schritt für Schritt mit Befehlen wie ein du -xhs /*.
David Schwartz
du -x -h / | sort -h | tail -40 | sort -h -rkann verwendet werden, um in absteigender Reihenfolge zu sortieren, wenn lesbare Ausgaben verwendet werden.
Vigs
14

Ich weiß, ich antworte in diesem Thread nach fast 5 Jahren, aber es könnte jemandem helfen, ich hatte das gleiche Problem, ich hatte m4.xlarge Instanz df -h sagte, dass die / dev / xvda1 voll war, - 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

Ich habe versucht, es zu lösen, hier sind die Schritte

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

Hat mir geholfen zu wissen, dass es der Docker-Container war, der meinen gesamten Speicherplatz belegte, also habe ich meinen gesamten Container in meine Docker-Registrierung verschoben und dann sudo rm -rf / var / lib / docker / es hat meinen Speicherplatz aufgeräumt :) Ich hoffe, es hilft jemandem :)

Swat
quelle
8

Wenn Sie eine EBS-Boot-Instanz ausführen (empfohlen), können Sie die Größe des Root-Volumes (/) mithilfe der in diesem Artikel beschriebenen Prozedur erhöhen:

Ändern der Größe der Root-Festplatte auf einer laufenden EBS Boot EC2-Instanz
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Wenn Sie eine Instanz des Instanzspeichers ausführen (nicht empfohlen), können Sie die Größe des Stammdatenträgers nicht ändern. Sie müssen entweder Dateien löschen oder Dateien in einen kurzlebigen Speicher verschieben (z. B. / mnt) oder EBS-Volumes anhängen und Dateien dorthin verschieben.

Hier ist ein Artikel, den ich geschrieben habe, der beschreibt, wie eine MySQL-Datenbank von der Root-Platte auf ein EBS-Volume verschoben wird:

Ausführen von MySQL unter Amazon EC2 mit EBS
http://aws.amazon.com/articles/1663

... und überlegen Sie, ob Sie zu EBS-Boot-Instanzen wechseln möchten. Es gibt viele Gründe, warum Sie sich später bedanken werden.

Eric Hammond
quelle
Ich verwende EBS, es ist ziemlich billig, die Root-Disc zu erweitern, oder? Zum Glück muss ich mich nicht mit MySQL auseinandersetzen, meine Projekte sind derzeit Mongo / Redis. ein tolles Material hier. +1
2

Ich bin vor kurzem auf dieses Problem bei Amazon Linux gestoßen. Meine crontab-Warteschlange für ausgehende E-Mails /var/spool/clientmqueuewar 4,5 GB groß.

Ich habe es gelöst durch:

  1. Suchen großer Dateien: sudo find / -type f -size +10M -exec ls -lh {} \;
  2. Löschen großer Dateien: /bin/rm -f <path-to-large-file>
  3. Starten Sie die Serverinstanz neu

Problem gelöst!

Gabe Karkanis
quelle
1

Ich habe dieses Problem gerade gelöst, indem ich diesen Befehl ausführe:

sudo apt autoremove

und viele alte Pakete wurden entfernt, wodurch 5 Gigabyte frei wurden, zum Beispiel gab es viele Pakete wie dieses "linux-aws-headers-4.4.0-1028"

Paulo
quelle