web-dev-qa-db-ja.com

xvda1は100％使用されていますが、それは何ですか？直し方？

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% /

問題は、このファイルが何であるかわからないことです。また、このファイルが問題であるかどうかもわかりません。

だから私の質問は、「デバイスに空き容量がありません」エラーを修正するにはどうすればよいですか？

linuxamazon-ec2xen
46
Chris Biscardi

そのファイル、/はルートディレクトリです。それがdfに表示される唯一のファイルシステムである場合は、それがすべてです。 1GBのファイルシステムがあり、100％使用されています。次のように、それがどのように使用されるかを理解することができます。

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

次に、/は、最も多くのスペースを使用しているパスに置き換えます。 （sortのおかげで、最後に表示されます。コマンドには時間がかかる場合があります。）

73
David Schwartz

私は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;}'

すべてのスペースを話しているのはDockerコンテナーであることを知るのを助けたので、すべてのコンテナーを私のDockerレジストリーにプッシュし、次にSudo rm -rf/var/lib/docker /を実行しました。 :)

16
Swat

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

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

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

これは、MySQLデータベースをルートディスクからEBSボリュームに移動する方法について記述した記事です。

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

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

8
Eric Hammond

最近、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. サーバーインスタンスを再起動します

問題が解決しました！

3
Gabe Karkanis

JenkinsやDockerが原因である可能性があります。これを解決するには、 Jenkinsログをクリーンアップし、そのサイズを設定する必要があります 。

1
T.Todua

私はこのコマンドを実行してその問題を解決しました：

Sudo aptの自動削除

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

1
Paulo