![奇怪的 GZip/磁盘空间问题](https://linux22.com/image/1299139/%E5%A5%87%E6%80%AA%E7%9A%84%20GZip%2F%E7%A3%81%E7%9B%98%E7%A9%BA%E9%97%B4%E9%97%AE%E9%A2%98.png)
我正在使用符合 PCI 分区规则的服务器,这意味着以下每个目录都有自己的分区:/、/var、/boot、/usr、/tmp 和 /home。该服务器目前正在使用 Apache / MySQL 后端托管一个网站。
我收到一条警告,说 /var 分区(大小为 2 GB)空间不足。我检查了一下,位于 /var/log/access.log 的 Apache 访问日志生成了大量文本:在没有设置日志轮换的情况下,大约 10 天内生成了 1 GB 左右的文本。
我重新配置了 Apache 设置,将日志放在具有更多空间的另一个分区上,并使用 gzip 压缩设置日志轮换。
奇怪的地方就在这里。旧的 Apache 访问日志位于 /var/log/access.log,未压缩时大约有 920 MB。/var 分区大约已满 80%,因此它使用了 2.0 GB 中的 1.6 GB。
我运行以下命令来压缩日志文件:
cd /var/log && gzip -9 access.log > access-2011-12-19.log.gz
我现在意识到我对 gzip 的使用有点生疏了,因为它创建了两个文件:access-2011-12-19.log.gz(空文件)和 access.log.gz(现在为 68 MB,包含原始的 920 MB 日志文件)。我删除了 access-2011-12-19.log.gz 文件,旧的日志文件现在不见了。
问题:然后我检查了 /var 分区上的空间,令我困惑的是,现在显示为 78% 已满,或大约 1.4 GB。
似乎将 920 MB 的日志文件压缩到 68 MB 应该可以节省大量磁盘空间,但事实似乎并非如此。可能是什么问题?如果有帮助的话,服务器正在运行 CentOS 6。
答案1
完成后多久gzip
检查磁盘使用情况?ping 的最后一步gzip
是删除原始文件。删除大型文件后,文件系统可能需要很长时间才能追踪并释放所有关联的 inode。我有时看到它需要几个小时,尽管那是在比你的文件大得多的文件上。
编辑后添加:另一种可能性是某个进程仍处于打开access.log
状态;甚至 Apache 可能仍在写入它?即使您从文件系统取消链接(“删除”)文件,只要有指向它的打开文件描述符,它就不会真正被删除。
另外,我应该提到——如果你想gzip
将压缩文件(或解压文件)写入标准输出,而不删除未压缩的原始文件(或压缩的原始文件),你可以指定该-c
选项。或者,你可以在标准输入上发送原始文件,而不是将其名称作为参数传递。因此,以下任一操作均可:
gzip -c -9 access.log > access-2011-12-19.log.gz
gzip -9 < access.log > access-2011-12-19.log.gz
(我个人倾向于使用后一种方法。)