xvda1は100%いっぱいですが、それは何ですか?直し方?


41

EC2でLinuxインスタンスを実行しています(MongoDBとnode.jsがインストールされています)。このエラーが表示されます。

Cannot write: No space left on device

私はそれをこのファイルまで追跡したと思います、これはdf出力です

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

問題は、このファイルが何なのかわからず、このファイルが問題なのかどうかもわかりません。

だから私の質問は次のとおりです。「デバイスにスペースが残っていません」エラーを修正するにはどうすればよいですか?

回答:


67

そのファイル/は、ルートディレクトリです。それがあなたが見る唯一のファイルシステムならdf、それはすべてです。1GBのファイルシステムがあり、100%満杯です。次のようにどのように使用されるかを理解し始めることができます。

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

その後/、最も多くのスペースを占有しているパスに置き換えることができます。(sort。のおかげで、最後になります。コマンドにはしばらく時間がかかる場合があります。)


19
人間が読める形式で出力を取得するには、sudo du -x -h / | sort -h | tail -40この回答から)を使用できます。
mkobit

マイクロAWS AMIインスタンスの場合、これを実行するには1分ほどかかります。我慢して!
ロブラング博士

これをどうするか:sort: write failed: /tmp/sortGmL8oF: No space left on device
dOM

1
@dOM痛い。上のいくつかのスペースをきれいにしてみてください/tmp。または、必要な場合は、などのコマンドを使用して段階的に絞り込みますdu -xhs /*
デビッドシュワルツ

du -x -h / | sort -h | tail -40 | sort -h -r人間が読める出力を使用する場合、降順でソートするために使用できます。
ビグ

14

私はほぼ5年後にこのスレッドで返信していることを知っていますが、それは誰かを助けるかもしれません、私は同じ問題を抱えていました、m4.xlargeインスタンスdf -hは/ dev / xvda1がいっぱいだったと言いました-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

私はここでそれを解決しようとしました

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

すべてのスペースを話しているのはドッカーコンテナであることを知るのに役立ちましたので、すべてのコンテナをドッカーレジストリにプッシュしてから、sudo rm -rf / var / lib / docker /を実行してスペースを空にしました:) :)


8

EBSブートインスタンスを実行している場合(推奨)、この記事で説明する手順を使用して、ルート(/)ボリュームのサイズを増やすことができます。

実行中のEBSブートEC2インスタンス上のルートディスクのサイズ変更
http://alestic.com/2010/02/ec2-resize-running-ebs-root

インスタンスストアインスタンスを実行している場合(推奨されません)、ルートディスクのサイズを変更することはできません。ファイルを削除するか、一時ストレージ(/ mntなど)にファイルを移動するか、EBSボリュームを接続してそこにファイルを移動する必要があります。

ルートデータベースからEBSボリュームにMySQLデータベースを移動する方法を説明した記事を次に示します。

EBSを使用してAmazon EC2でMySQLを実行する
http://aws.amazon.com/articles/1663

...そしてEBSブートインスタンスへの移行を検討してください。後で感謝する理由はたくさんあります。


EBSで実行していますが、ルートディスクを適切に拡張するのはかなり安価ですか?幸い、MySQLを扱う必要はありません。私のプロジェクトは現在Mongo / Redisです。ここにいくつかの素晴らしい資料があります。+1

2

最近、Amazon Linuxでこの問題に遭遇しました。私のcrontab送信メールキュー/var/spool/clientmqueueは4.5GBでした。

私はそれを解決しました:

  1. 大きなファイルを見つける: sudo find / -type f -size +10M -exec ls -lh {} \;
  2. 大きなファイルの削除: /bin/rm -f <path-to-large-file>
  3. サーバーインスタンスを再起動する

問題が解決しました!


1

この問題を解決するには、次のコマンドを実行します。

sudo apt autoremove

そして、多くの古いパッケージが削除され、5ギガバイトが解放されました。たとえば、この「linux-aws-headers-4.4.0-1028」のような多くのパッケージがありました


弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.