диск повний, але не можна знайти великі файли чи папки


20

Сервер Ubuntu показує мені, що я використовую allmost весь диск:

Usage of /:   95.5% of 118.12GB

І я намагаюся знайти великі папки та файли, запустити ncdu:

ncdu 1.8 ~ Use the arrow keys to navigate, press ? for help                                                                                                                                                 
--- / ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    5.5GiB [##########] /root                                                                                                                                                                               
    2.3GiB [####      ] /var
  628.6MiB [#         ] /usr
  209.9MiB [          ] /lib
   28.2MiB [          ] /boot
    8.6MiB [          ] /bin
    7.7MiB [          ] /sbin
    6.6MiB [          ] /etc
  208.0KiB [          ] /run
  112.0KiB [          ] /tmp
   48.0KiB [          ] /opt
e  16.0KiB [          ] /lost+found
    8.0KiB [          ] /dev
    8.0KiB [          ] /media
    4.0KiB [          ] /lib64
e   4.0KiB [          ] /srv
e   4.0KiB [          ] /selinux
e   4.0KiB [          ] /mnt
e   4.0KiB [          ] /home
    0.0  B [          ] /proc
    0.0  B [          ] /sys
@   0.0  B [          ]  initrd.img
@   0.0  B [          ]  vmlinuz

Згідно ncduя використовую близько 10 GiBз 128 GiB- це про 10 %. Протиріччя.

Як очистити моєму ubutntu serverбез перезавантаження?

Я думав, що це ncduбрехня, і використовував інші додатки, щоб знайти великі файли та папки. Усі вони показують однаковий результат, як ncdu.

І df -hкоманда показує, що диск заповнений.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda       119G  113G     0 100% /
udev            2.0G  8.0K  2.0G   1% /dev
tmpfs           788M  212K  788M   1% /run
none            5.0M     0  5.0M   0% /run/lock
none            2.0G     0  2.0G   0% /run/shm

Оновлення

sudo du -sch /* результат:

/# sudo du -sch /*
8.7M    /bin
29M /boot
8.0K    /dev
6.6M    /etc
4.0K    /home
0   /initrd.img
210M    /lib
4.0K    /lib64
16K /lost+found
8.0K    /media
4.0K    /mnt
48K /opt
du: cannot access `/proc/4470/task/4470/fd/4': No such file or directory
du: cannot access `/proc/4470/task/4470/fdinfo/4': No such file or directory
du: cannot access `/proc/4470/fd/4': No such file or directory
du: cannot access `/proc/4470/fdinfo/4': No such file or directory
0   /proc
5.0G    /root
212K    /run
7.8M    /sbin
4.0K    /selinux
4.0K    /srv
0   /sys
112K    /tmp
629M    /usr
2.3G    /var
0   /vmlinuz
8.1G    total

8.1G як завжди. Але я бачу cannot accessрядки, можливо, проблеми через них.

Тоді я перевірив найбільшу папку в /. Це /root:

/# sudo du -sch /root/*
96K /root/Downloads
2.5G    /root/Dropbox
36K /root/nohup.out
4.0K    /root/npm-debug.log
4.0K    /root/readonly
980K    /root/redis-2.6.16.tar.gz
228M    /root/tmp
2.7G    total

Лише думка, може перевірити вміст / var / log /, щоб побачити, чи якісь журнали виросли експоненційно.
Мордок

/ var / log близько 2 Гб. Це нормально
Максим Єфремов

1
Спробуйте du -sch /*побачити, які кореневі каталоги використовують найбільше місця, і спустіться звідти в місця, використовуючи найбільше місця.
DopeGhoti

@DopeGhoti Я спробував, але побачив те саме про 8.1 GiBповне (додав це для оновлення). Не можу зрозуміти, де інше100 GiB
Максим Єфремов

2
Я знаю, що ви цього не хочете, але кулі та перезавантажте.
douggro

Відповіді:


13

Я стикався з цим самим питанням на наших лабораторних машинах і використовував цю команду

du -sch .[!.]* * |sort -h

Мені вдалося знайти приховані файли, як-от всередині урни для сміття користувачів, які вони ще повинні видалити.

Подяка тут, де я спочатку знайшов цю відповідь.


Дивовижне рішення!
АйванФ.

5

Перевірте, чи є видалені файли, які все ще залишаються відкритими в процесі:
sudo lsof | grep deleted | less

Це покаже дескриптор pid та файлів. У мене була така точна проблема на сервері, нічого, ncduкрім заповнення диска. Це виявився нічним процесом, який переміщував файли на змонтовану спільну частину самби і час від часу не вимикав роботу файлу правильно, здається.

Якщо ви знайдете видалені файли і хочете їх очистити, перезавантаження, мабуть, найлегше, якщо це прийнятно. Або ви можете спробувати вбити процес. Або якщо ви впевнені, що їх не використовують, ви можете вручну зняти їх з нуля таким чином:
> /proc/14487/fd/12


Це було моє питання. Tomcat тримав видалений файл на 80 Гб. Для його виправлення було достатньо перезавантаження.
AFP_555

Як їх видалити, якщо команди "перезавантажити" недостатньо?
виблискуйте

4

Наступна команда покаже використання диска для / домашнього каталогу з --max-width = 1

user@linux:~$ sudo du -h -d 1 /

2

Обов’язково перевірте кріплення вашого диска. Жодне з розглянутих тут рішень не може визначити простір, який займає папка, над якою розміщено кріплення.


Я думаю, це може бути моєю проблемою
Eliethesaiyan,


В основному, перевірте наявні версії за допомогою mount, а потім додайте другу версію для кожного з каталогів, які мають кріплення над ними. Тоді ви можете використовувати звичайні дискові інструменти, як duна новоствореному кріпленні, щоб побачити, чи не винен він.
Річ Ремер

1

У нас був цей самий випуск, і він виявився зображеннями докера, що зберігаються під var / lib / docker

ncdu не перераховує їх, оскільки вони не видимі користувачам. навіть запуск ncdu під судо не допомагає.

Ця команда очищує всі існуючі зображення докера ...

docker rmi $(docker images -a -q)


Тут же питання. Насправді навіть docker system pruneне знайшов усе. Ця команда (яка передує докерській системі обрізки) виконує свою справу.
jscharf

1
нещодавно ми виявили, що docker system prune -a -fце набагато ретельніше
Болді

0

Ви можете виконати наступну команду, щоб знайти топ-10 найбільших файлів:

find / -type f -printf '%s %p\n' 2>&1 
     | grep -v 'Permission denied' 
     | sort -nr 
     | head -10
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.