方法一:
du -lh --max-depth=1 /path
先在/path目录下找出最大的目录path1,然后再在path1下找出最大的目录,这样一级一级就可以找出占用空间最大的目录了
du -lh --max-depth=1 /path/path1
方法二:
du -sh /* 查看占用的大小,找到最大目录后继续往里找
运行 df 命令:
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/VG00-LV01
50G 47G 16M 100% /
发现确实有个分区被占满了。。。
第一次碰到这种情况,继续google之,使用如下命令
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:
Filesystem Inodes IUsed IFree IUse% 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命令:
FilesystemSize Used Avail Use% Mounted on
/dev/mapper/VG00-LV01
50G 47G 16M 100% /
仍然还是100%,明明已经删除了啊。。。 不解,继续google之。。
结论是“在Linux中,当我们使用rm在linux上删除了大文件,但是如果有进程打开了这个大文件,却没有关闭这个文件的句柄,那么linux内核还是不会释放这个文件的磁盘空间,最后造成磁盘空间占用100%,整个系统无法正常运行。这种情况下,通过df和du命令查找的磁盘空间,两者是无法匹配的,可能df显示磁盘100%,而du查找目录的磁盘容量占用却很小。”
找出文件使用者,kill掉:
lsof -n | grep deleted
找到使用ssl_error_log文件的进程,kill掉,然后再次df -h,发现已经没有100%的情况了。