磁盘缓慢填满，但文件大小无明显变化

16

df 

 Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda1       30830588 22454332   6787120  77% /
none                   4        0         4   0% /sys/fs/cgroup
udev             1014124        4   1014120   1% /dev
tmpfs             204996      336    204660   1% /run
none                5120        0      5120   0% /run/lock
none             1024976        0   1024976   0% /run/shm
none              102400        0    102400   0% /run/user

昨天这77％只是60％，几天之内就会达到100％。

我已经监视文件大小一段时间了： 

sudo du -sch /*


9.6M    /bin
65M     /boot
224K    /build
4.0K    /dev
6.5M    /etc
111M    /home
0       /initrd.img
0       /initrd.img.old
483M    /lib
4.0K    /lib64
16K     /lost+found
8.0K    /media
4.0K    /mnt
4.0K    /opt
du: cannot access ‘/proc/21705/task/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/task/21705/fdinfo/4’: No such file or directory
du: cannot access ‘/proc/21705/fd/4’: No such file or directory
du: cannot access ‘/proc/21705/fdinfo/4’: No such file or directory
0       /proc
21M     /root
336K    /run
12M     /sbin
8.0K    /srv
4.1G    /swapfile
0       /sys
4.0K    /tmp
1.1G    /usr
7.4G    /var
0       /vmlinuz
0       /vmlinuz.old
14G     total

每天都在给我（或多或少）相同的数字。这14G的总容量不到磁盘大小的一半。剩下的去哪儿了？

我对Linux的了解并不深入。

文件可能不会在这里显示吗？是否可以通过其他任何方式分配空间？

filesystem  disk-usage 
— izz
source
1
您的7.4 G /var震撼到了我。我怀疑日志文件正在快速填充。
— 乔斯
4
有删除的文件吗？会做什么lsof -b 2>/dev//null | grep deleted（输出可能会很大，迭代地
— 删除
@muru是的，一堆文件以这种方式显示。这是什么意思？他们在哪？我该如何清洁？
— nizzle
2
重新启动后应该会清理掉其中的很多东西。它们只是由各种进程打开的文件，然后被删除。拥有一些是正常的，但是如果其中一个变得太大，您将不会有一种简单的方法来发现它du。
— muru
1
请注意，您可能要提出第二个问题，涉及logrotate.conf出了什么问题，因为应该将apache配置为在发生日志记录时关闭文件等。之所以这样说是因为重新启动现在可以解决问题，但是除非我遗漏了某些东西，否则您的该问题应定期重现，而每周必须重新启动会令人不快。[我建议它是否重复出现，看看服务httpd是否再次重新启动（或重新加载）可以暂时缓解此问题
— Foon

Answers:

28

如果磁盘空间出现无形的增长，则可能是删除文件的罪魁祸首。在Windows中，如果尝试删除由某物打开的文件，则会出现错误。在Linux中，该文件将被标记为已删除，但是数据将一直保留到应用程序释放为止。在某些情况下，这可以用作一种清理自己的整洁方式 -应用程序崩溃不会阻止清除临时文件。

要查看已删除但仍在使用的文件：

lsof -b 2>/dev/null | grep deleted

您可能有大量已删除的文件-这本身不是问题。一个删除的文件变大是一个问题。

重新启动应该可以解决此问题，但是如果您不想重新启动，请检查涉及的应用程序（lsof输出中的第一列），然后重新启动或关闭外观合理的应用程序。

如果您看到以下内容：

zsh   1724   muru   txt   REG   8,17   771448   1591515  /usr/bin/zsh (deleted)

如果应用程序和删除的文件相同，则可能意味着应用程序已升级。您可以忽略那些导致大量磁盘使用的原因（但是您仍然应该重新启动程序，以便应用错误修复程序）。

其中的文件/dev/shm是共享内存对象，不会在磁盘上占用太多空间（我认为最多是一个inode数）。也可以安全地忽略它们。命名vteXXXXXX的文件是来自基于VTE的终端仿真器（如GNOME Terminal，Terminator等）的日志文件。如果您打开的终端窗口中有很多（我的意思是很多）正在输出的东西，这些可能会很大。

— uru
source
1
在OP的系统上，整个/ dev是udev挂载点，因此该目录下的任何内容都不会占用主文件系统上的任何空间。此外，/ dev / shm通常无论如何都是作为tmpfs实现的，这也只是一个安装点，因此它下面的单个文件甚至都不会占用目录入口空间。
— 凯文
3

要添加到muru的出色答案中：

  • df显示磁盘上的大小，
  • du显示文件内容的总大小。

也许您在du中看不到的是很多小文件的外观……（查看文件的最后一列，df -i看inode的数量（即文件的数量）是否也增加了很多时间）

如果您碰巧有1'000'000（100万个）小1字节文件，du则将其计为1'000'000字节，例如1Mb（...纯粹主义者，请不要畏缩）

但是在磁盘上，每个文件由两部分组成：

  • 1个索引节点（指向文件的数据），该索引节点本身可以​​是16kb（！），
  • 每个文件的数据（=文件的内容）都放在磁盘块上，这些块不能包含多个文件数据（通常...），因此您的1字节数据将至少占据1个块

因此，一百万个文件的1字节文件将占据1'000'000'000 * size_of_a_block数据的总空间，加上1'000'000'000 * size_of_an_inodeinode的大小...对于一百万个“ 1字节”的文件来说，这可能相当于几GB的磁盘使用量。

如果您有1024字节的块，以及inode大小的另一个256字节，那么您的1'000'000文件将被报告为大约1Mb du，但在磁盘上将被视为大约1.25Gb（如所见df）！（如果每个inode也必须位于1个专用磁盘块上，则甚至为2Gb，我不知道是这种情况）

— 奥利维尔·杜拉克（Olivier Dulac）
source
1
除非您明确使用一个选项（-b或--apparent-size）告诉du您显示文件的外观大小，du否则实际上将始终显示该文件在磁盘上的大小（已用块总数乘以块大小）。实际上，它可以比文件的表观大小更大（在正常情况下）或较小（在稀疏文件的情况下）。
— 乔纳森·卡伦
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.