压缩以提高硬盘写入性能

Question

在现代系统上，通过压缩输出流可以提高本地硬盘写入速度吗？

这个问题来源于我正在使用的一个案例，其中一个程序连续生成并将1-2GB的文本日志记录数据转储到硬盘上的原始文本文件中，我认为它是IO绑定的。我希望能够通过在数据进入磁盘之前压缩数据来减少运行时间，还是压缩的开销会占用我可以获得的任何增益？有空闲的第二个核心会影响这个吗？

我知道这会受到用于生成数据的CPU数量的影响，所以对需要多少空闲CPU时间的经验很好。

---

我记得有人使用压缩来提高数据库的读取速度，但是IIRC压缩比解压缩更加耗费CPU。

Answer 1

是的，是的，是的，绝对。

以这种方式看待它：以每秒兆字节为单位获取最大连续磁盘写入速度。 （继续测量它，计算一个巨大的fwrite或其他东西。）让我们说100mb / s。现在以CPU为单位，以兆赫为单位;让我们说3Ghz = 3000mhz。将CPU速度除以磁盘写入速度。这是CPU空闲的周期数，您可以在压缩时花费每字节。在这种情况下，每个字节3000/100 = 30个周期。

如果你的算法可以将数据压缩25％以获得有效的125mb / s写入速度，那么每个字节有24个周期来运行它并且它基本上是 free 因为在等待磁盘流失时，CPU不会做任何其他事情。每个字节24个周期=每个128字节高速缓存行3072个周期，很容易实现。

我们在阅读光学媒体时一直这样做。

如果你有一个闲置的第二个核心，那就更容易了。只需将日志缓冲区移交给该核心的线程，只要它喜欢压缩数据就可以，因为它没有做任何其他事情！唯一棘手的一点是你想要实际拥有一个缓冲区环，这样你就没有生成器线程（生成日志的那个）在互斥锁上等待消费者线程（将其写入磁盘的那个）的缓冲区抱着。

Answer 2

是的，至少10年都是如此。有关于它的操作系统论文。我认为Chris Small可能会对其中一些人有所帮助。

对于速度而言，较低质量级别的gzip / zlib压缩非常快;如果速度不够快，您可以尝试FastLZ 。使用额外核心的快捷方法是使用popen(3)通过gzip发送输出。

Answer 3

对于Sun的文件系统来说，ZFS能够实现动态压缩，以减少磁盘IO的数量而不会显着增加开销，这在实践中就是一个例子。

Answer 4

Filesystems and storage lab from Stony Brook今年IBM's SYSTOR systems research conference在paper at ACM Digital Library presentation发布了对服务器系统上文件数据压缩的相当广泛的性能（和能量）评估：{{3}}，{{3}}。

结果取决于

• 使用压缩算法和设置，
• 文件工作量和
• 您机器的特性。

例如，在本文的测量中，使用文本工作负载和使用 lzop进行低压缩工作的服务器环境比普通写入更快，但bzip和gz不是。

在您的具体设置中，您应该尝试并测量。它确实可以提高性能，但情况并非总是如此。

Answer 5

CPU的增长速度比硬盘访问速度快。即使在80年代，也可以从磁盘上读取许多压缩文件，并且在比读取原始（未压缩）文件所花费的时间更短的时间内解压缩文件。那不会改变。

通常情况下，压缩/解压缩的处理级别低于您编写的级别，例如在数据库I / O层中。

关于第二个核心的用处，只考虑系统是否还要执行大量其他工作 - 并且您的程序必须是多线程的才能利用额外的CPU。

Answer 6

以二进制形式记录数据可能是一项快速改进。您将减少对磁盘的写入，并且CPU将花费更少的时间将数字转换为文本。如果人们要阅读日志，它可能没用，但他们也无法读取压缩日志。

Answer 7

Windows已经支持NTFS中的文件压缩，因此您所要做的就是在文件属性中设置“压缩”标志。 然后，您可以衡量它是否值得。

Answer 8

如果它只是文本，那么压缩肯定会有所帮助。只需选择压缩算法和设置，使压缩成本低廉。 “gzip”比“bzip2”便宜，并且两者都有参数可以调整以支持速度或压缩比。

Answer 9

这取决于很多因素，我认为没有一个正确的答案。归结为：

考虑到可用于此目的的CPU带宽，您能否比原始写入性能更快地压缩原始数据的速度乘以您实现的压缩比（或者您尝试获得的速度倍数）？

考虑到今天10英寸/秒的相对较高的数据写入速率，这是一个相当高的障碍来克服。对于其他一些答案，您可能必须具有易于压缩的数据，并且只需要通过一些合理性类型实验的测试对其进行基准测试并找出答案。

相对于特定意见（猜测！？）到关于额外核心的观点。如果你对数据进行压缩并保持核心数据的压缩率 - 文本的压缩率很高，那么这种技术可能会带来一些成果。但这只是猜测。在磁盘写入和压缩操作之间交替的单线程应用程序中，对我来说似乎不太可能。

Answer 10

如果你是I / O绑定保存人类可读文本到硬盘驱动器，我希望压缩可以减少你的总运行时间。

如果您有一个空闲的2 GHz内核，以及相对较快的100 MB / s流式硬盘， 将净记录时间减半需要至少2：1压缩，每个未压缩字节不超过大约10个CPU周期，以便压缩器思考数据。 使用双管道处理器，每个字节（非常粗略地）20个指令。

我看到LZRW1-A（最快的压缩算法之一）每个字节使用10到20个指令，并且压缩典型的英文文本大约2：1。 在高端（每个字节20条指令），您就在IO绑定和CPU绑定之间的边缘。在中间和低端，你仍然是IO限制，所以有一些循环可用（不多）一个稍微复杂的压缩器来稍微思考一下数据。

如果您有一个更典型的非顶级硬盘驱动器，或者由于某些其他原因（碎片，使用磁盘的其他多任务处理等）硬盘驱动器速度较慢 那么你有更多时间让更复杂的压缩器来思考数据。

您可以考虑设置压缩分区，将数据保存到该分区（让设备驱动程序压缩它），并将速度与原始速度进行比较。 与改变程序和链接压缩算法相比，这可能花费更少的时间并且不太可能引入新的错误。

我看到list of compressed file systems based on FUSE，我听说NTFS也支持压缩分区。

Answer 11

如果这个特定的机器经常是IO绑定的， 另一种加快速度的方法是安装RAID阵列。 这将为每个程序和各种数据（甚至是不可压缩的数据）提供加速。

例如，流行的RAID 1 + 0配置，总共有4个磁盘，速度接近2倍。

几乎同样流行的RAID 5配置，总共有4个磁盘，速度接近3倍。

设置一个速度是单个驱动器速度8倍的RAID阵列相对简单。

另一方面，高压缩比显然不是那么简单。将“仅仅”6.30压缩为一个可以获得现金奖励以打破当前的压缩世界纪录（Hutter Prize）。

Answer 12

这曾经是一种可以在很多应用程序中提高性能的方式。我想今天它不太可能得到回报，但它可能在你的特定情况下，特别是如果你记录的数据很容易压缩，

然而，正如Shog9所评论的那样：

  

经验法则无济于事   你在这里。这是你的磁盘，你的CPU，   和你的数据。设置一个测试用例和   测量吞吐量和CPU负载   没有压缩 - 看看是不是   值得权衡。