打开/处理 580GB 错误日志文件的建议答案

【问题标题】：Advice for opening/handling a 580GB error log file打开/处理 580GB 错误日志文件的建议
【发布时间】：2012-01-18 23:08:51
【问题描述】：

一个朋友让我帮他写一个简单的 php 脚本，我把它放在他们的 Wordpress 网站上。在这样做的过程中，我遇到了一些我认为可以帮助他解决的明显问题。然后我遇到了野兽。

一个 580 GB 的错误日志文件。

这是一个简单的博客，每月有数百万的浏览量和千兆字节的图片，但他不应该对它进行一些维护吗？我知道在大多数情况下我可以tail -f 日志文件，但我认为它可能会使行星在试图打开这么大的文本文件时发生碰撞。

问题

我应该告诉他只是擦除它并从现在开始重新监控它，还是有适当的方法来查看过去 10 天的日志？我没有在他们的服务器上花费足够的时间（只是浏览了 FTP）来查看他们在运行什么。

【问题讨论】：

创建此日志文件的原因是什么？显然，此日志记录过程需要在旋转/归档/截断日志文件方面进行改进。
0_0 如果时间戳很容易解析，那么您可能需要编写一个小脚本来读取文件并仅将最后 X 天的数据（对于合理的 X 值）复制到单独的文件。然后你就可以杀死怪物日志文件了。
这可能更适合服务器故障。我还认为，如果您将问题更改为有关打开大文件或仅打开文本文件末尾部分的问题，您更有可能得到答案。
哦，所以投票结束，没有任何解释。一定会喜欢的。可以评论任何解释或要求提供更多信息。伙计们，我在这里问了一个完全合理的问题。
也许不是关闭它，而是应该迁移到 serverfault 左右。虽然我没有看到问题，因为处理此文件可能涉及一些编程。

【解决方案1】：

这会给你最后 100 行：

tail -n 100 logfile > last-100-lines.log

就“日期”而言，您还可以：

cat |grep '2012-12' > all-dec.log

不是，grep 的确切术语取决于日志文件的外观。这两个操作都需要一点时间来运行。如果这个应用程序是磁盘密集型的，你可能会因为磁盘饱和而遇到问题，因为这个怪物非常大，你不太可能有 600+ GB 的 RAM 并且该日志文件缓存在内存中。 ;-)

无论如何，为了好玩，试试bzip2 --best logfile 然后下载它，然后在 localhost 上评估它。

处理这么大的文件并不漂亮，但应该可行。

【讨论】：

grep 仍然需要通读整个文件才能找到它感兴趣的部分，这将需要很长时间。 tail 可能足够聪明，可以从末尾开始向后移动寻找换行符，但我不知道。
@Till - 感谢您的建议，尽管正如我上面提到的，使用此代码必须首先实际打开文件本身，对吗？打开这么大的文件似乎几乎是不可能的。此外，通过 T1 线路下载文件（即使是 bzip）的理想方式让我很头疼。
是的，grep 肯定会遍历整个文件。这将需要更多的资源来处理。如果资源是一个问题，我建议在压缩之前下载它。 bzip2 也是磁盘密集型的。
流量（~0.5 TB）是否值得关注？
我刚刚在一堆日志文件上尝试了tail。它一定很聪明，看起来几乎是瞬间的。 cat 和 grep 慢很多。

【解决方案2】：

您可以编写一个程序来打开文件，寻找比文件大小小 1 GB 的偏移量，然后将从此点开始的所有内容复制到另一个文件。这样您就可以提取最新的日志，而不会导致大量磁盘 I/O 读取所有旧的东西。如果您想根据日期进行过滤，请在较新的较小文件上进行，而不是原来的大文件。

查看文件的其他部分以了解为什么文件这么大也是一个好主意。例如，是否有某个信息被重复了很多次？我会做一些统计抽样：在文件中选择一堆随机位置，然后从每个位置读取大约一千字节。同样，直接寻找你要阅读的地方，而不是从头开始阅读所有内容。

【讨论】：

【解决方案3】：

正如我们所说，我怀疑这发生在全世界数十亿个应用程序中。日志文件在硬盘驱动器上堆积数据，有时会连续数年，有时会被遗忘。

虽然有些applications 提供mecanisms 来协助日志文件的数据收集和压缩，但您最终仍然必须“思考”，无论您存储数据，它往往会随着时间的推移而堆积，如果数据是分布在多个来源的位经常被遗忘。这是一个关于堆栈溢出的奇怪问题，但希望答案有所帮助。

【讨论】：

也许更适合 Serverfault，但我相信这是许多 Web 开发人员，也许是 WP 或 PHP 编码人员都面临的问题，所以如果可能的话，只想获得一系列意见。感谢您的洞察力。