我们的一位服务器管理员让我看一下这个问题,但我很困惑 - 我们的 /var 分区已满,但我似乎无法确定空间去了哪里。
以下是“du /var -ah”的输出
...
202M var/
然而 'df -h' 返回
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/gza-root 268M 108M 147M 43% /
tmpfs 2.0G 0 2.0G 0% /lib/init/rw
udev 10M 68K 10M 1% /dev
tmpfs 2.0G 0 2.0G 0% /dev/shm
/dev/sda1 236M 20M 204M 9% /boot
/dev/mapper/gza-home 115G 15G 95G 14% /home
/dev/mapper/gza-tmp 380M 11M 350M 3% /tmp
/dev/mapper/gza-usr 4.7G 3.9G 610M 87% /usr
/dev/mapper/gza-var 2.9G 2.7G 26M 100% /var
我似乎无法找到另外 2.5GB 去了哪里,有什么想法或提示吗?
答案1
尝试重新启动服务。当您删除(rm unlink things, it)某个文件时,某些文件可能在 /var 上打开。系统将不会释放空间,直到所有文件都关闭该文件的文件句柄。
您可能需要使用lsof找出哪个程序仍在 /var 中打开文件。
因为它是/var,所以我猜测某些东西仍然有一个打开的日志文件。
答案2
有几种可行的方法可以实现此目的:
- 您的 inode 是否用完了,而不是可用块(实际空间)用完了?如果有很多小文件,它们可能会占用所有 inode(实际上是文件分配表中的条目)。一旦所有 inode 都用完了,即使分区中有大量可用块,您也无法添加新文件。这是一个通配符答案,用于检查是否存在明显的证据。inode 耗尽的情况很少见,但仍会发生(Blackboard 7.0...)
du -s /var/* | sort -rn
应该可以让你更好地了解 /var 中占用空间的内容,就像 KDirStat 这样的图形实用程序一样。我不建议使用 KDirStat 来解决这个问题,因为你正在处理 /var。与 /home 的空间问题相比,/var 的问题往往会影响系统稳定性。此外,在专用服务器的情况下,你首先不应该在机器上运行 GUI,这使得使用(本地)GUI 工具的想法变得毫无意义。在不太紧急的情况下,KDirStat、WinDirStat 和 SequoiaView 等工具的方形树形图输出使问题识别变得微不足道;树形图是可视化磁盘使用情况的绝佳方式。- 是否有某些服务失控,将大量垃圾记录到 /var/log?如果您的组织文化接受它,那么设置专用日志主机并让所有机器通过网络将日志写入它可能会很有价值。至少,确保根据您网站的日志保留策略适当地轮换、压缩和删除每个日志。logrotate 是您的好朋友。
- 你做有日志保留策略,对吧?;)说真的,如果你没有,那就设置一个。可以是一句话 - “除非与服务所有者做出其他安排,否则我们将保留七天的日志。以书面形式。”
答案3
您是否有权限访问 /var 下的所有文件夹?du 不会报告您无权访问的内容所用的空间。
答案4
我想知道当你询问你的机器还剩下多少个 inode 时它会告诉你什么。在分区上存储数据的能力不仅仅是空闲块数量的函数...