it-swarm.com.de

xvda1 ist zu 100% voll. Was ist das? wie repariert man?

Ich führe eine Linux-Instanz auf EC2 aus (ich habe MongoDB und node.js installiert) und erhalte folgende Fehlermeldung:

Cannot write: No space left on device

Ich glaube, 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 Speicherplatz mehr auf dem Gerät"?

46
Chris Biscardi

Diese Datei / Ist Ihr Stammverzeichnis. Wenn es das einzige Dateisystem ist, das Sie in df sehen, dann ist es alles. Sie haben ein 1-GB-Dateisystem 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 den meisten Platz beanspruchen. (Sie werden dank sort am Ende sein. Der Befehl kann eine Weile dauern.)

73
David Schwartz

Ich weiß, dass ich in diesem Thread nach fast 5 Jahren antworte, 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 hier zu lösen, 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 sprach, 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 :) :)

16
Swat

Wenn Sie eine EBS-Startinstanz ausführen (empfohlen), können Sie die Größe des Root-Volumes (/) mithilfe des in diesem Artikel beschriebenen Verfahrens 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 Instanzspeicherinstanz ausführen (nicht empfohlen), können Sie die Größe der Root-Festplatte nicht ändern. Sie müssen entweder Dateien löschen oder Dateien in einen kurzlebigen Speicher (z. B./mnt) verschieben oder EBS-Volumes anhängen und Dateien dorthin verschieben.

In diesem Artikel habe ich beschrieben, wie eine MySQL-Datenbank von der Root-Festplatte auf ein EBS-Volume verschoben wird:

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

... und ziehen Sie in Betracht, zu EBS-Boot-Instanzen zu wechseln. Es gibt viele Gründe, warum Sie sich später bedanken werden.

8
Eric Hammond

Ich bin kürzlich auf dieses Problem unter Amazon Linux gestoßen. Meine ausgehende Crontab-E-Mail-Warteschlange /var/spool/clientmqueue war 4,5 GB.

Ich habe es gelöst durch:

  1. Große Dateien suchen: Sudo find / -type f -size +10M -exec ls -lh {} \;
  2. Große Dateien löschen: /bin/rm -f <path-to-large-file>
  3. Starten Sie die Serverinstanz neu

Problem gelöst!

3
Gabe Karkanis

Es könnte von Jenkins oder Docker kommen. Um dies zu lösen, sollten Sie Jenkins-Protokolle bereinigen und deren Größe festlegen .

1
T.Todua

Ich habe dieses Problem gerade durch Ausführen dieses Befehls gelöst:

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

1
Paulo