xvda1 заполнен на 100%, что это? как исправить?

Я запускаю экземпляр Linux на EC2 (у меня установлены 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% /

Проблема в том, что я не знаю, что это за файл, и я также не знаю, является ли этот файл проблемой.

Итак, мой вопрос: как я могу исправить ошибку «Нет свободного места на устройстве»?

Этот файл /является вашим корневым каталогом. Если это единственная файловая система, которую вы видите df, тогда это все. У вас есть файловая система 1 ГБ, и она заполнена на 100%. Вы можете начать понимать, как это используется следующим образом:

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

Затем вы можете заменить /пути, которые занимают больше всего места. (Они будут в конце, благодаря sort. Команда может занять некоторое время.)

Я знаю, что отвечаю в этой теме почти через 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 /, он очистил мое пространство :) надеюсь, это кому-нибудь поможет :)

Если вы запускаете загрузочный экземпляр EBS (рекомендуется), вы можете увеличить размер корневого (/) тома, используя процедуру, описанную в этой статье:

Изменение размера корневого диска на работающем загрузочном экземпляре EBS EC2
http://alestic.com/2010/02/ec2-resize-running-ebs-root

Если вы используете экземпляр хранилища экземпляров (не рекомендуется), вы не сможете изменить размер корневого диска. Вы должны либо удалить файлы, либо переместить файлы в временное хранилище (например, / mnt), либо присоединить тома EBS и переместить туда файлы.

Вот статья, которую я написал, которая описывает, как перенести базу данных MySQL с корневого диска на том EBS:

Запуск MySQL на Amazon EC2 с EBS
http://aws.amazon.com/articles/1663

... и подумайте о переходе на загрузочные экземпляры EBS. Есть много причин, почему вы будете благодарить себя позже.

Я недавно столкнулся с этой проблемой на Amazon Linux. Моя очередь исходящей электронной почты crontab /var/spool/clientmqueueсоставляла 4,5 ГБ.

Я решил это:

1. Расположение больших файлов: sudo find / -type f -size +10M -exec ls -lh {} \;
2. Удаление больших файлов: /bin/rm -f <path-to-large-file>
3. Перезапустите экземпляр сервера

Проблема решена!

Я только что решил эту проблему с помощью этой команды:

sudo apt autoremove

и много старых пакетов было удалено, освобождая 5 гигабайт, например, было много таких пакетов, как «linux-aws-headers-4.4.0-1028»

Это может быть от Дженкинса или Докера. Чтобы решить эту проблему, вы должны очистить журналы Jenkings и установить его размер .