在管理Linux系统时,我经常发现自己在分区已满后仍在努力寻找罪魁祸首。我通常使用du / | sort -nr,但是在大型文件系统上,返回任何结果要花很长的时间。 du在更微妙的情况下,然后不得不在输出中进行拖曳。

我宁愿使用依赖于标准Linux命令的命令行解决方案,因为我必须管理许多系统和安装新软件很麻烦(尤其是在磁盘空间不足时!)

评论

@Bart感谢您抽出宝贵的时间在这里改善帖子,但是在添加标签时,我是否可以请您多加注意?标签不是为了可见,而是描述了问题。磁盘标签在这里不合适(请参见其标签说明),并且您在此建议的编辑中添加的至少两个标签在那里不合适(Kali不是Debian,并且不涉及PPA)。 br />
我处于完全相同的情况,并且也在寻找命令行解决方案。但是,我确实要指向filelight(KDE,Linux和Windows)或baobab(Gnome),它们(类似于macOS上的DaisyDisk)提供了出色的图形径向可视化。如果您有图形化的环境,它们会给您带来额外的舒适感!

#1 楼

尝试使用ncdu这个出色的命令行磁盘使用分析器:



评论


通常,我讨厌被要求安装一些东西来解决一个简单的问题,但这很好。

– gwg
16年7月5日在18:58

在ubuntu上安装sudo apt install ncdu会很容易。这很棒

– Orion Edwards
17年7月19日在22:30

您很可能知道哪个文件系统空间不足。在这种情况下,可以使用ncdu -x仅将与正在扫描的目录相同的文件系统上的文件和目录计数。

–卢克·考辛斯(Luke Cousins)
17年7月21日在11:51

最佳答案。另外:sudo ncdu -rx /应该仅在根区域驱动器上对最大的目录/文件进行干净的读取。 (-r =只读,-x =保留在同一文件系统上(表示:不要遍历其他文件系统安装))

– bshea
17-09-21在15:52



我的空间太小,无法安装ncdu

–克里斯
18年6月14日在16:57

#2 楼

不要直接进入du /。使用df查找损害您的分区,然后尝试du命令。

我想尝试的一种是

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


,因为它以“人类可读的形式”打印尺寸。除非您的分区非常小,否则对gb目录进行grepping可以很好地满足您的需求。这将花费一些时间,但是除非您设置了配额,否则我认为这就是原来的方式。

正如@jchavannes在评论中指出的那样,如果您发现太多误报。我纳入了建议,虽然确实可以使建议更好,但是仍然存在误报,因此存在一些折衷(expr更简单,结果更糟; expr更复杂和更长,结果更好)。如果输出中显示的目录太小,请相应地调整正则表达式。例如,

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


更准确(不会列出<1GB目录)。

如果有配额,则可以使用

quota -v


查找正在占用磁盘的用户。

评论


这是非常快速,简单和实用的

– zzapper
2012年10月29日在16:43

grep'[0-9] G'包含很多误报,并且省略了任何小数。这对我来说更好:sudo du -h / | grep -P'^ [0-9 \。] + G'

– jchavannes
2014年8月14日6:09



@jchavannes -P对于此表达式是不必要的,因为那里没有特定于Perl的内容。同样,-P不能移植到没有GNU实现的系统。

–本·柯林斯
14年8月14日在18:11

如果您的目录很大,则需要[GT]而不是G

–维特鲁威
15年3月28日在20:20

我喜欢用du -h | -hr |头

–augustar
16年6月13日在18:48

#3 楼

首先,请使用du的“摘要”视图:

 du -s /*
 


是打印其每个参数的大小,即上述情况下的每个根文件夹。

此外,GNU du和BSD du都可以进行深度限制(但是POSIX du不能!):



GNU(Linux,…):

 du --max-depth 3
 



BSD(macOS,…):


du -d 3



这将限制输出显示的深度3.当然,计算和显示的尺寸仍然是整个深度的总和。但是,尽管如此,限制显示深度还是可以极大地加快计算速度。可读”输出(即使用KiB,MiB等)。

评论


如果du抱怨-d,请改为尝试--max-depth 5。

–ReactiveRaven
13年7月2日在11:25

太棒了。对我来说似乎正确。我建议du -hcd 1 / directory。 -h表示可读,c表示总计,d表示深度。

– Thales Ceolin
2014年2月4日,1:13

我使用du -hd 1 <文件夹检查> | -hr |头

– jonathanccalixto
17年1月10日,19:39



du --max-depth 5 -h / * 2>&1 | grep'[0-9 \。] \ + G'| -hr |过滤头权限被拒绝

–srghma
17年9月1日在10:36

#4 楼

您还可以使用du运行以下命令:

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



-s选项汇总并显示每个参数的总数。

h打印Mio,Gio等。

x =停留在一个文件系统中(非常有用)。

P =不遵循符号链接(这可能会导致文件计数)例如两次)。

小心,不会显示/root目录,您必须运行~# du -Pshx /root 2>/dev/null才能知道(一次,我很努力地指出了我的/root目录已满) 。

编辑:更正了选项-P

评论


du -Pshx。* * 2> / dev / null +隐藏/系统目录

–迈克
16 Feb 15'在10:16



/ root /显示没有问题。为什么不显示?

– Atralb
1月20日20:04

#5 楼

在文件系统上查找最大的文件总是需要很长时间。根据定义,您必须遍历整个文件系统以查找大文件。唯一的解决方案可能是在所有系统上运行cron作业,以提前准备好文件。

另一件事,du的x选项对防止du跟踪装入点进入有用。其他文件系统。即:

du -x [path]


我通常运行的完整命令是:

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


-m表示返回结果兆字节,并且sort -rn将首先对结果最大数量进行排序。然后,您可以在编辑器中打开usage.txt,最大的文件夹(以/开头)将位于顶部。

评论


感谢您指出-x标志!

– SamB
2010年6月2日于20:55

“找到最大的文件需要很长时间。”->这要看情况,但往往会不同意:对于ncdu之类的实用工具并不需要花费那么长时间-至少比du或find更快(取决于深度和参数)。

– bshea
17/09/21在15:35



由于我不想成为root用户,因此我不得不修改文件的写入位置:sudo du -xm / |排序-rn>〜/ usage.txt

–布鲁诺
18-09-14在6:55

#6 楼

我总是使用du -sm * | sort -n,它为您提供了当前工作目录的子目录用完了多少的排序列表,以兆字节为单位。

您也可以尝试Konqueror,它具有“大小视图”模式,这类似于WinDirStat在Windows上所做的操作:它可以直观地表示哪些文件/目录占用了您的大部分空间。

更新:在最新版本中,您还可以使用du -sh * | sort -h显示人类可读的文件大小并按这些大小排序。 (数字后缀有K,M,G等)。

对于那些寻找KDE3 Konqueror文件大小视图替代品的人,可以看看filelight,尽管它并不那么好。

评论


不过,那只是Konqueror 3.x-文件大小视图仍未移植到KDE4。

–麻烦
09年2月9日在19:09

'du -sh * | sort -h'在我的Linux(Centos发行版)机器上完美工作。谢谢!

–pahariayogi
17年4月25日在14:05

#7 楼

我将其用于当前目录下前25名最严重的违法者

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


评论


此命令的技巧在于找到一个隐藏的文件夹,该文件夹似乎随着时间的推移而增加。谢谢!

–thegreendroid
13年6月20日在2:24

以字节为单位吗?

–用户
2014年9月17日下午0:12

默认情况下,在我的系统上,“ du -S”给出了很好的人类可读输出。对于小文件,您将获得一个普通的字节数,对于大文件,您将获得一个带有'KB'或'MB'后缀的数字。

– serg10
2014-09-17 8:48

@Siddhartha如果添加-h,则可能会更改sort -nr命令的效果-意味着排序将不再起作用,然后head命令也将不再起作用

–克莱尔·麦克雷(Clare Macrae)
17年12月4日13:00



在Ubuntu上,我需要使用-h来读取人类可读的数字,以及使用sort -h来进行人类数字的排序。该列表是反向排序的,因此请使用tail或更改顺序。

– ar鱼
18年8月30日在8:41



#8 楼

在以前的公司中,我们曾经做过一项cron作业,该作业会整夜运行,并识别出一定大小的任何文件,例如

find / -size +10000k


搜索目录,并注意所有可能脱机的远程安装驱动器。

评论


您可以使用find的-x选项来确保在find命令的起点之外的其他设备上找不到文件。这解决了远程安装驱动器的问题。

– rjmunro
2015年6月29日在16:29



#9 楼

我使用

du -ch --max-depth=2 .


,并更改最大深度以适合我的需要。 “ c”选项打印文件夹的总计,“ h”选项打印相应的K,M或G大小。正如其他人所说,它仍然扫描所有目录,但是它以我发现更容易找到大目录的方式限制了输出。

#10 楼

一种选择是将您的du / sort命令作为cron作业运行,并输出到文件,因此在您需要时该文件已经存在。

#11 楼

对于命令行,我认为du / sort方法是最好的。如果您不在服务器上,则应查看Baobab-磁盘使用情况分析器。该程序也需要一些时间才能运行,但是您可以轻松找到所有旧Linux ISO所在的子目录。

评论


它还可以通过SSH,FTP,SMB和WebDAV扫描远程文件夹。

– Sponsz上校
08年2月2日在16:34

这很棒。使用GUI可视化它们可以使某些事情更好地工作,这就是其中之一!无论如何,我的服务器上都需要一个X服务器来进行CrashPlan,因此它也可以在该服务器上运行。

– timelmer
16年6月25日在20:46

#12 楼

我要第二次xdiskusage。但是我要补充一点,它实际上是一个du前端,可以读取文件中的du输出。因此,您可以在服务器上运行du -ax /home > ~/home-du,返回文件,然后以图形方式对其进行分析。或通过ssh传递它。

#13 楼

尝试将du的输出输入到一个简单的awk脚本中,该脚本检查目录的大小是否大于某个阈值,如果可以,则将其打印出来。开始获取信息之前,您不必等待遍历整棵树(相对于其他答案)。例如,以下显示的所有目录所消耗的资源都不止于500 MB。

du -kx / | awk '{ if ( > 500000) { print 
dubig() {
    [ -z "" ] && echo "usage: dubig sizethreshMB [dir]" && return
    du -kx  | awk '{ if ( > ''*1024) { print q4312078q} }'
}
} }'


要使上面的内容更可重用,可以在.bashrc中定义一个函数(或者可以将其变成独立的脚本) 。

q4312078q

因此,dubig 200 ~/会在主目录下(不带关闭设备的符号链接)查找使用超过200 MB的目录。

评论


遗憾的是,更多的grep骇客遭到更多批评。哦,du -k可以绝对确定du使用的是KB单位

– ndemou
16年11月23日在20:05

关于-k的好主意。编辑。

–马克·博格丁
16年11月24日在11:16

更简单,更强大:du -kx $ 2 | awk'$ 1>'$((($ 1 * 1024)))(如果仅指定条件aka模式来awk,则默认操作为print $ 0)

–dave_thompson_085
16-11-27在11:31



好点@ date_thompson_085。我所知道的所有版本的awk(net / free-BSD&GNU)都是如此。 @ mark-borgerding,所以这意味着您可以将第一个示例大大简化为du -kx / |。 awk'$ 1> 500000'

– ndemou
16 Dec 13'9:46

@ mark-borgerding:如果您只剩下几千字节,您也可以像这样使用du -kx / |保留du的整个输出。 tee /tmp/du.log | awk'$ 1> 500000'。这非常有帮助,因为如果您的第一次过滤结果无效,则可以尝试使用类似awk'$ 1> 200000'/tmp/du.log的其他值,或者检查诸如sort -nr /tmp/du.log |的完整输出。更少而无需重新扫描整个文件系统

– ndemou
16 Dec 13'9:59



#14 楼

这里没有提到,但是如果删除/挂起文件,还应该检查lsof。我从失控的cronjob中删除了5.9GB的tmp文件。

https://serverfault.com/questions/207100/how-can-i-find-phantom-storage-usage帮助我了找到上述文件的进程所有者(cron),然后我可以减少问题文件的数量,以开始逃跑,解决这个问题,然后回显“”>文件以清理空间并让cron优雅地关闭自己。

#15 楼

我喜欢用旧的xdiskusage作为du(1)的图形替代。

评论


注意问题的这一部分:“由于……,我宁愿使用依赖于标准Linux命令的命令行解决方案”

– ndemou
17年7月4日在20:20

#16 楼

我更喜欢使用以下内容进行概述并从那里进行追溯...

cd /folder_to_check
du -shx */


这将显示具有人类可读输出的结果,例如GB,MB。它还将防止遍历远程文件系统。 -s选项仅显示找到的每个文件夹的摘要,因此如果您对文件夹的更多详细信息感兴趣,则可以进一步深入研究。请记住,此解决方案将仅显示文件夹,因此如果您也需要文件,则希望在星号后省略/。

#17 楼

您可以使用findsort之类的标准工具来分析磁盘空间使用情况。

列出按大小排序的目录:

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


列出文件按大小排序:

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


评论


我发现这是最好的答案,可以按顺序检测大尺寸

–克里希纳
17年10月1日在11:16

#18 楼

在终端上,您可以使用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


查看网站上的所有使用详细信息

#19 楼

也许值得一提的是,默认情况下,mc(Midnight Commander,经典的文本模式文件管理器)仅显示目录inode的大小(通常为4096),但使用CtrlSpace或菜单工具时,您可以在其中查看所选目录所占用的空间人类可读的格式(例如103151M之类的格式)。

例如,下图显示了2018和2017的原始TeX Live发行版的完整大小,而2015和2016的版本仅显示了inode的大小(但它们的确接近每个5 Gb)。

也就是说,CtrlSpace必须一对一地完成,仅针对实际目录级别,但是在使用mc导航时它是如此的快捷方便,以至于您可能不需要ncdu(实际上,仅出于此目的更好)。否则,您也可以从ncdu运行mc。无需退出mc或启动另一个终端。



#20 楼

对于命令行du(及其选项)似乎是最好的方法。 DiskHog看起来也使用cron作业中的du / df信息,因此Peter的建议可能是简单有效的最佳组合。
(FileLight和KDirStat非常适合GUI。)

#21 楼

首先,我检查目录的大小,如下所示:

du -sh /var/cache/*/


#22 楼

如果您知道最近几天已经添加了大文件(例如3),则可以将find命令与“ ls -ltra”结合使用以发现那些最近添加的文件:

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


这只会给您文件(“ -type f”),而不是目录;仅对最近3天具有修改时间的文件(“ -mtime -3”)并对找到的每个文件(“ ls -lart”部分)执行“ -exec”。

#23 楼

要了解不成比例的磁盘空间使用情况,通常从根目录开始并逐步遍历其最大的子目录通常很有用。将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


,依此类推。 ..

#24 楼

我已使用此命令查找大于100Mb的文件:

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


#25 楼

还在?也许这个答案已经被认可...

虽然其他答案中描述了各种图形工具,但它们并不能解决解决识别您如何释放的潜在问题空间。

我目前正在研究同一个问题,并且遇到过agedu-报告访问时间和大小。我还没有机会玩这个游戏-它是由西蒙·塔瑟姆(Simon Tatham)撰写的(您可能听说过PuTTy),因此可能是明智/可靠的。

但是,像这里列出的所有工具一样,它按需收集数据。即使是最快的硬件上最有效的编码,也需要花费一些时间才能遍历一个alt-terrabyte文件系统。

评论


如果您不能使用GUI(例如在远程服务器上),则ncdu -e可以很好地工作。显示屏打开后,请先按m再按M进行显示并按mtime进行排序,同时(仍然很小)百分比图仍然存在,以使您了解大小。

–西他拉姆
19年8月24日在12:53

“如果您不能使用GUI(就像您在远程服务器上),”-为什么远程服务器会阻止您使用GUI?

–symcbean
19年8月24日在16:02

#26 楼

我已经成功地找到了最糟糕的违规者,将以人类可读形式输出的du输出到egrep并匹配了正则表达式。

例如:

它应该带回您500兆或更高的一切。

评论


不要将grep用于算术运算-改为使用awk:du -k | awk'$ 1> 500000'。第一次尝试时,它更容易理解,编辑和正确。

– ndemou
17年7月4日在20:25

#27 楼

如果需要速度,则可以在要监视的文件系统上启用配额(无需为任何用户设置配额),并使用使用quota命令的脚本来列出每个用户正在使用的磁盘空间。例如:

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


将以块为单位为特定文件系统上的特定用户提供磁盘使用情况。您应该可以通过这种方式在几秒钟内检查使用情况。

要启用配额,您需要将usrquota添加到/ etc / fstab文件中的文件系统选项中,然后可能重新启动以便进行quotacheck可以在调用quotaon之前在空闲的文件系统上运行。

#28 楼

这是一个微型应用程序,它使用深度采样来查找任何磁盘或目录中的肿瘤。它遍历目录树两次,一次进行测量,第二次打印出目录下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.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.1\em64t\bin\tselect.exe
.\Intel\Download\IntelFortranProCompiler91\Compiler\Itanium\Data1.cab
.\Intel\MKL.0.1\em64t\bin\mkl_lapack32.dll
.\Java\jre1.6.0\bin\client\classes.jsa
.\Microsoft SQL Server\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.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\MUI09\moviemk.chm
.\TheCompany\TheProduct\docs\TheProduct User's Guide.pdf
.\VNI\CTT6.0\help\StatV1.pdf
7,908,634,694


它告诉我该目录为7.9gb,其中


大约有15%的资源用于Intel Fortran编译器
〜15%的资源用于VS .NET 2003
〜20%的资源用于VS 8

很简单地询问是否有这些文件可以卸载。

它还介绍了在文件系统中分布的文件类型,但它们在一起代表了节省空间的机会:


〜 15%大约用于.cab和.MSI文件
〜10%大约用于记录文本文件

它也显示了很多其他内容,我可能没有这些支持“ SmartDevices”和“ ce”(约15%)。

确实需要线性时间,但是不必经常这样做。

示例它有找到:


不需要真正保存的许多已保存代码存储库中DLL的备份副本
服务器上某人硬盘驱动器的备份副本晦涩的目录
大量的临时Internet文件
远古时代需要的文档和帮助文件


#29 楼

我遇到了类似的问题,但是此页面上的答案还不够。我发现以下命令对清单最有用:

du -a / | sort -n -r | head -n 20

哪一位将告诉我20个最大的违法者。但是,即使我运行了此文件,它也没有显示出真正的问题,因为我已经删除了该文件。问题在于,仍有一个仍在运行的进程正在引用已删除的日志文件...所以我不得不先杀死该进程,然后磁盘空间显示为可用。

评论


很好,但这应该是评论,而不是单独的答案-这个问题的答案太多

– ndemou
17年9月9日在10:36

#30 楼

您可以使用DiskReport.net生成所有磁盘的在线Web报告。

运行多次,它将为您显示所有文件夹的历史记录图,轻松查找增长的原因

评论


该工具与“在分区已满后我经常发现自己难以追究罪魁祸首”和“我宁愿依赖标准Linux命令的命令行解决方案”这个问题的两个要点不符。

– ndemou
17年9月9日在10:35