linux查看tmp目录大小,linux查看目录占用空间大小

方法1 :

du -lh --max-depth=1 /path

在/path目录下找到最大的目录path1，然后在path1下找到最大的目录。 这样可以找到第1级占用空间最大的目录

du -lh --max-depth=1 /path/path1

方法2 :

检查du -sh /*占用大小，找到最大的目录后继续在里面查找

运行df命令：

filesystemsizeusedavailuse % mounted on

/dev/mapper/VG00-LV01

50G 47G 16M 100% /

我确实发现分区已经满了。

第一次遇到这种情况时，继续谷歌的，然后使用以下命令

du -sh /* | sort -nr

获得/目录下所有文件和目录大小的排序结果。

从中找到最大的，在我的机器里/var文件占用了47个g的大小，我想就是它了。 使用上面的命令继续跟踪：

du -sh /var/* | sort -nr

du -sh /var/log/* | sort -nr

du -sh /var/log/httpd/* | sort -nr

一层一层往下走，最后发现httpd/目录下的ssl_error_log占用了超大型的磁盘空间。 从文件的内容来看，可能是某个链接多次反复写入了大量的错误信息。

请不要考虑，直接删除此文件。

运行df -i:

filesysteminodesiusedifreeiuse % mounted on

/dev/mapper/VG00-LV01

3276800 226882 3049918 7% /

tmpfs 4069835 7 4069828 1% /dev/shm

/dev/md0 51200 39 51161 1% /boot

/dev/mapper/VG00-LV02

56705024 11756 56693268 1% /opt

大使使用量不大是因为-i是查看inode情况时与文件大小不同的概念。

重新运行df -h命令：

filesystemsizeusedavailuse % mounted on

/dev/mapper/VG00-LV01

50G 47G 16M 100% /

还是100%。 明明删除了啊。 困惑地继续谷歌的。

结论：“在Linux上，使用rm删除了Linux上的大文件，但如果进程打开此大文件，但没有句柄来关闭此文件，则Linux内核不会释放此文件的磁盘空间，最终磁盘空间会变为在这种情况下，df和du命令搜索的磁盘空间不匹配。 df可能显示100%的磁盘，但du搜索目录中的磁盘空间很小。 ”

找到文档用户，然后降低技能：

lsof-n

找到使用ssl_error_log文件的进程，kill后再次df -h，发现已经没有100%的情况了。