Разыскивание, где дисковое пространство пошло на Linux?

Я использую это для 25 самых серьезных нарушителей, находящихся ниже текущего каталога

# -S to not include subdir size, sorted and limited to top 25
du -S . | sort -nr | head -25

Я перейду на второй xdiskusage . Но я собираюсь добавить примечание, что на самом деле это интерфейс du и может читать вывод du из файла. Таким образом, вы можете запустить du -ax / home> ~ / home-du на своем сервере, scp вернуть файл, а затем проанализировать его графически. Или пропустите его через ssh.

Один из вариантов - запустить вашу команду du / sort как задание cron и вывести ее в файл, чтобы она уже была там, когда вам это нужно.

Для первого взгляда используйте «сводное» представление du :

du -s /*

Эффект заключается в том, чтобы напечатать размер каждого из его аргументов, то есть каждой корневой папки в приведенном выше случае.

Кроме того, как GNU du , так и BSD du могут иметь ограничение по глубине (, но POSIX du не может! ):

• GNU (Linux,…):

   du --max-depth 3 
   

• BSD (macOS,…):

   du -d 3 
   

Это ограничит отображение вывода глубиной 3. Рассчитанный и отображаемый размер, конечно, по-прежнему является суммой полной глубины. Но, несмотря на это, ограничение глубины отображения резко ускоряет вычисления.

Еще одна полезная опция - -h (слова как в GNU, так и в BSD, но, опять же, не в POSIX-only du ) для «удобочитаемого» вывода (т. Е. С использованием KiB, MiB и т. Д. ).

Это крошечное приложение, которое использует глубокую выборку для поиска опухолей на любом диске или в любом каталоге. Он проходит по дереву каталогов дважды: один раз для его измерения, а второй раз для распечатки путей к 20 «случайным» байтам в каталоге.

void walk(string sDir, int iPass, int64& n, int64& n1, int64 step){
    foreach(string sSubDir in sDir){
        walk(sDir + "/" + sSubDir, iPass, n, n1, step);
    }
    foreach(string sFile in sDir){
        string sPath = sDir + "/" + sFile;
        int64 len = File.Size(sPath);
        if (iPass == 2){
            while(n1 <= n+len){
               print sPath;
               n1 += step;
            }
        }
        n += len;
    }
}

void dscan(){
    int64 n = 0, n1 = 0, step = 0;
    // pass 1, measure
    walk(".", 1, n, n1);
    print n;
    // pass 2, print
    step = n/20; n1 = step/2; n = 0;
    walk(".", 2, n, n1);
    print n;
}

Вывод для моего каталога Program Files выглядит следующим образом:

 7,908,634,694
.\ArcSoft\PhotoStudio 2000\Samples\3.jpg
.\Common Files\Java\Update\Base Images\j2re1.4.2-b28\core1.zip
.\Common Files\Wise Installation Wizard\WISDED53B0BB67C4244AE6AD6FD3C28D1EF_7_0_2_7.MSI
.\Insightful\splus62\java\jre\lib\jaws.jar
.\Intel\Compiler\Fortran\9.1\em64t\bin\tselect.exe
.\Intel\Download\IntelFortranProCompiler91\Compiler\Itanium\Data1.cab
.\Intel\MKL\8.0.1\em64t\bin\mkl_lapack32.dll
.\Java\jre1.6.0\bin\client\classes.jsa
.\Microsoft SQL Server\90\Setup Bootstrap\sqlsval.dll
.\Microsoft Visual Studio\DF98\DOC\TAPI.CHM
.\Microsoft Visual Studio .NET 2003\CompactFrameworkSDK\v1.0.5000\Windows CE\sqlce20sql2ksp1.exe
.\Microsoft Visual Studio .NET 2003\SDK\v1.1\Tool Developers Guide\docs\Partition II Metadata.doc
.\Microsoft Visual Studio .NET 2003\Visual Studio .NET Enterprise Architect 2003 - English\Logs\VSMsiLog0A34.txt
.\Microsoft Visual Studio 8\Microsoft Visual Studio 2005 Professional Edition - ENU\Logs\VSMsiLog1A9E.txt
.\Microsoft Visual Studio 8\SmartDevices\SDK\CompactFramework\2.0\v2.0\WindowsCE\wce500\mipsiv\NETCFv2.wce5.mipsiv.cab
.\Microsoft Visual Studio 8\VC\ce\atlmfc\lib\armv4i\UafxcW.lib
.\Microsoft Visual Studio 8\VC\ce\Dll\mipsii\mfc80ud.pdb
.\Movie Maker\MUI\0409\moviemk.chm
.\TheCompany\TheProduct\docs\TheProduct User's Guide.pdf
.\VNI\CTT6.0\help\StatV1.pdf
7,908,634,694

Он сообщает мне, что размер каталога составляет 7,9 ГБ, из которых

• ~ 15% идет на компилятор Intel Fortran
• ~ 15% идет на VS .NET 2003
• ~ 20% идет на VS 8

Достаточно просто спросить, можно ли что-нибудь из них выгрузить.

В нем также говорится о типах файлов, которые распределены по файловой системе, но вместе взятые представляют возможность для экономии места:

• ~ 15% примерно идет на файлы .cab и .MSI
• ~ 10% примерно идет для протоколирования текстовых файлов

Здесь также показано множество других вещей, без которых я, вероятно, мог бы обойтись, например, поддержка "SmartDevices" и "ce" (~ 15%).

Это действительно требует линейного времени, но это не нужно делать часто.

Примеры того, что он обнаружил:

• резервные копии библиотек DLL во многих репозиториях сохраненного кода, которые действительно не нуждаются в сохранении
• резервной копии чьего-либо жесткого диска на сервер в неизвестном каталоге
• объемные временные файлы Интернета
• старые документы и файлы справки, которые давно уже не нужны

Если вы знаете, что большие файлы были добавлены в последние несколько дней (скажем, 3), затем вы можете использовать команду find в сочетании с « ls -ltra », чтобы обнаружить эти недавно добавленные файлы:

find /some/dir -type f -mtime -3 -exec ls -lart {} \;

Это даст вам только файлы (« -тип f "), а не каталоги; только файлы со временем модификации за последние 3 дня (« -mtime -3 ») ​​и выполните « ls -lart » для каждого найденного файла (« -exec "часть).

Я использовал эту команду для поиска файлов размером более 100 МБ:

find / -size +100M -exec ls -l {} \;

Для командной строки du (и ее параметры) кажется лучшим способом. DiskHog выглядит так, как будто он также использует информацию du / df из задания cron, поэтому предложение Питера , вероятно, является лучшим сочетанием простого и эффективного.

( FileLight и KDirStat идеально подходят для графического интерфейса пользователя.)

У меня была подобная проблема, но ответы на этой странице были недостаточно. Я нашел следующую команду, чтобы быть самым полезным для листинга:

DU -A / | Сортировать -N -R | Head -N 20

, который покажет мне 20 крупнейших преступников. Однако, хотя я побежал это, это не показать мне реальную проблему, потому что я уже удалил файл. Уловив состоял в том, что произошел процесс, который все еще работает, который ссылался на удаленный файл журнала ... поэтому я должен был сначала убить этот процесс, то пробел дисков, то, как было представлено бесплатно.

Попробуйте ncdu , отличный анализатор использования диска из командной строки:

Чтобы понять непропорциональное использование дискового пространства, часто бывает полезно начать с корневого каталога и пройти через некоторые из его самых больших дочерних директорий.

Мы можем сделать это,

• сохранив вывод du в файл
• итеративно просматривая результат

То есть:

# sum up the size of all files and directories under the root filesystem
du -a -h -x / > disk_usage.txt
# display the size of root items
grep $'\t/[^/]*$' disk_usage.txt

теперь допустим, что / usr кажется слишком большим

# display the size of /usr items
grep $'\t/usr/[^/]*$' disk_usage.txt

теперь, если / usr / local подозрительно большой

# display the size /usr/local items
grep $'\t/usr/local/[^/]*$' disk_usage.txt

и так далее ...

Можно использовать DiskReport.net для создания онлайн-отчета обо всех дисках.

Во время многих запусков он покажет вам график истории для всех ваших папок, легко найти то, что выросло

Я предпочитаю использовать следующее, чтобы получить обзор и развернуть оттуда ...

cd /folder_to_check
du -shx */

Это будет отображать результаты с удобочитаемым выводом, таким как ГБ, МБ. Это также предотвратит обход удаленных файловых систем. Параметр -s показывает только сводку по каждой найденной папке, поэтому вы можете развернуть ее дальше, если хотите получить более подробную информацию о папке. Имейте в виду, что это решение будет отображать только папки, поэтому вы захотите опустить / после звездочки, если вам тоже нужны файлы.

Поиск самых больших файлов в файловой системе всегда занимает много времени. По определению вы должны пройти всю файловую систему в поисках больших файлов. Единственное решение, вероятно, - запустить задание cron на всех ваших системах, чтобы файл был готов заранее.

Еще одна вещь: опция x для du полезна для предотвращения перехода du к точкам монтирования в другие файловые системы. Я.e:

du -x [path]

Полная команда, которую я обычно выполняю, выглядит так:

sudo du -xm / | sort -rn > usage.txt

-m означает возврат результатов в мегабайтах, а sort -rn сначала отсортирует результаты по наибольшему номеру. Затем вы можете открыть usage.txt в редакторе, и самые большие папки (начиная с /) будут вверху.

Я всегда использую du -sm * | sort -n , который дает вам отсортированный список использования подкаталогов текущего рабочего каталога в мебибайтах.

Вы также можете попробовать Konqueror, у которого есть режим «просмотра размеров», который похож на то, что делает WinDirStat в Windows: он дает вам визуальное представление о том, какие файлы / каталоги занимают большую часть вашего пространства.

Обновление: в более поздних версиях вы также можете использовать du -sh * | sort -h , который покажет удобочитаемые размеры файлов и отсортирует их по ним. (числа будут иметь суффикс K, M, G, ...)

Те, кто ищет альтернативу представлению размера файла KDE3 Konqueror, могут взглянуть на filelight, хотя это не так хорошо.

Не переходите сразу на du / . Используйте df , чтобы найти раздел, который причиняет вам боль, а затем попробуйте команды du .

Мне нравится пробовать

# U.S.
du -h <dir> | grep '[0-9\.]\+G'
# Others
du -h <dir> | grep '[0-9\,]\+G'

, потому что он печатает размеры в "удобочитаемой форме". Если у вас нет действительно маленьких разделов, поиск каталогов в гигабайтах - довольно хороший фильтр для того, что вы хотите. Это займет у вас некоторое время, но, если у вас нет квот, я думаю, что так оно и будет.

Как отмечает @jchavannes в комментариях, выражение может стать более точным, если вы обнаружите слишком много ложных срабатываний. Я включил предложение, которое делает его лучше, но все еще есть ложные срабатывания, поэтому есть только компромиссы (более простое выражение, худшие результаты; более сложное и длинное выражение, лучшие результаты). Если у вас слишком много маленьких каталогов, отображаемых в вашем выводе, соответствующим образом скорректируйте свое регулярное выражение. Например,

grep '^\s*[0-9\.]\+G'

является еще более точным (каталоги размером менее 1 ГБ не отображаются).

Если у вас есть квоты, вы можете использовать

quota -v

, чтобы найти пользователей, которые перегружают диск.

Вы также можете выполнить следующую команду, используя du :

~# du -Pshx /* 2>/dev/null

• Параметр -s суммирует и отображает итого по каждому аргументу.
• h печатает Mio, Gio и т. Д.
• x = оставаться в одной файловой системе (очень полезно).
• P = не следовать символическим ссылкам (например, это может привести к двойному подсчету файлов).

Будьте осторожны, каталог / root не будет отображаться, вам нужно запустить ~ # du -Pshx / root 2> / dev / null , чтобы получить это (один раз, Я много боролся, не указывая, что мой каталог / root переполнен).

Редактировать: Исправлена ​​опция -P

Здесь не упоминается, но вы также должны проверить lsof в случае удаления / зависания файлов. У меня был удаленный tmp-файл размером 5,9 ГБ из-за сбежавшего cronjob.

https://serverfault.com/questions/207100/how-can-i-find-phantom-storage-usage Помог мне найти владельца процесса указанного файла (cron), и тогда я смог перейти к / proc / {cron id} / fd / {дескриптор файла #} минус файл, о котором идет речь, чтобы начать запуск, разрешите это, а затем эхо ""> файл, чтобы очистить space и позвольте cron изящно закрываться.

Если вам нужна скорость, вы можете включить квоты для файловых систем, которые вы хотите отслеживать (вам не нужно устанавливать квоты для любого пользователя) и используйте сценарий, который использует команду quota для перечисления дискового пространства, используемого каждым пользователем. Например:

quota -v $user | grep $filesystem | awk '{ print $2 }'

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

Чтобы включить квоты, вам нужно будет добавить usrquota к параметрам файловой системы в вашем файле / etc / fstab, а затем, возможно, перезагрузиться, чтобы quotacheck можно было запустить в неактивной файловой системе до вызова quotaon.

Сначала я проверяю размер каталогов, например:

du -sh /var/cache/*/

Мне удалось отследить наихудшего (-ых) нарушителя (-ов), передавая вывод du в удобочитаемой форме в egrep и соответствие регулярному выражению.

Например:

du -h | egrep "[0-9]+G.*|[5-9][0-9][0-9]M.*"

, который должен вернуть вам все 500 мегабайт или больше.

В предыдущей компании у нас было задание cron, которое запускалось на ночь и определяло все файлы определенного размера, например,

find / -size +10000k

Возможно, вы захотите быть более избирательными в отношении каталогов, в которых вы проводите поиск, и следить за любыми удаленно подключенными дисками, которые могут выйти из сети.

Мне нравится старый добрый xdiskusage как графическая альтернатива du (1).

Попробуйте передать вывод du в простой сценарий awk, который проверяет, не превышает ли размер каталога некоторого порогового значения, и если да, то он распечатывает его. Вам не нужно ждать , пока будет пройдено все дерево, прежде чем вы начнете получать информацию (в отличие от многих других ответов).

Например, ниже показаны все каталоги, которые занимают более 500 МБ.

du -kx / | awk '{ if ($1 > 500000) { print $0} }'

Чтобы сделать вышесказанное более удобным для повторного использования, вы можете определить функцию в вашем .bashrc (или превратить ее в отдельный скрипт).

dubig() {
    [ -z "$1" ] && echo "usage: dubig sizethreshMB [dir]" && return
    du -kx $2 | awk '{ if ($1 > '$1'*1024) { print $0} }'
}

Итак, dubig 200 ~ / ищет в домашнем каталоге (без следующих символических ссылок с устройства) каталоги, которые используют более 200 МБ.

Для командной строки я думаю, что метод du/sort является лучшим. Если вы не на сервере, вам стоит взглянуть на Baobab - Disk usage analyzer. Эта программа также занимает некоторое время, но вы можете легко найти подкаталог глубоко, глубоко внизу, где находятся все старые Linux ISO.

Я использую

du -ch --max-depth=2 .

и изменяю максимальную глубину в соответствии с моими потребностями. Опция "c" печатает итоговые значения для папок, а опция "h" печатает размеры в K, M или G, в зависимости от ситуации. Как уже говорили другие, он по-прежнему сканирует все каталоги, но ограничивает вывод таким образом, что мне легче находить большие каталоги.

Вы можете использовать стандартные инструменты, такие как find и sort для анализа использования дискового пространства.

Список каталогов, отсортированных по размеру:

find / -mount -type d -exec du -s "{}" \; | sort -n

Список файлов, отсортированных по размеру:

find / -mount -printf "%k\t%p\n" | sort -n

Существует хорошая кроссплатформенная бесплатная программа под названием JDiskReport , которая включает графический интерфейс для изучения того, что занимает все это пространство.

Пример снимка экрана:

Конечно, вам нужно освободить немного места вручную, прежде чем вы сможете загрузить и установить его или загрузить на другой диск (например, флэш-накопитель USB).

(скопировано из ответа того же автора на повторяющийся вопрос)

Из терминала вы можете получить визуальное представление об использовании диска с помощью dutree

Он очень быстрый и легкий, потому что реализован на Rust

$ dutree -h
Usage: dutree [options] <path> [<path>..]

Options:
    -d, --depth [DEPTH] show directories up to depth N (def 1)
    -a, --aggr [N[KMG]] aggregate smaller than N B/KiB/MiB/GiB (def 1M)
    -s, --summary       equivalent to -da, or -d1 -a1M
    -u, --usage         report real disk usage instead of file size
    -b, --bytes         print sizes in bytes
    -f, --files-only    skip directories for a fast local overview
    -x, --exclude NAME  exclude matching files or directories
    -H, --no-hidden     exclude hidden files
    -A, --ascii         ASCII characters only, no colors
    -h, --help          show help
    -v, --version       print version number

См. всю информацию об использовании на веб-сайте

Возможно, стоит отметить, чтоmc(Midnight Commander, файловый менеджер классического текстового -режима )по умолчанию показывает только размер индексных дескрипторов каталога (обычно 4096), но с CtrlПробел или с помощью меню Инструменты вы можете увидеть пространство, занимаемое выбранным каталогом, в удобочитаемом формате (, например, некоторые вроде103151M).

Например, на рисунке ниже показан полный размер ванильных дистрибутивов TeX Live 2018 и 2017 годов, в то время как версии 2015 и 2016 годов показывают только размер инода (, но на самом деле они имеют около 5 Гб каждый ).

То есть, CtrlПробел нужно делать один к одному, только для фактического уровня каталога, но это так быстро и удобно, когда вы перемещаетесь с помощью mc, что, возможно, вы не нужноncdu(что действительно, только для этого лучше ). В противном случае вы также можете запустить ncduиз mc. без выхода из mcили запустить другой терминал.