压缩以提高硬盘写入性能答案

【问题标题】：Compression to Improve Hard Disk Write Performance压缩以提高硬盘写入性能
【发布时间】：2010-09-30 16:52:17
【问题描述】：

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

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

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

我记得一个视频谈话，有人使用压缩来提高数据库的读取速度，但 IIRC 压缩比解压缩更占用 CPU。

【问题讨论】：

经验法则在这里对您没有帮助。它是您的磁盘、您的 CPU 和您的数据。设置一个测试用例，并在压缩和不压缩的情况下测量吞吐量和 CPU 负载 - 看看是否值得权衡。
我想我的问题是值得我花时间运行测试吗？如果有人尝试过这个，我可以从那里得到很多结果（但是，是的，我仍然需要测试我的设置）。
@BCS - 具有额外的核心和优化的文本压缩器，它可以处理您的序列化数据 - 我认为它可能值得一试。文本压缩 10:1 类型的数字和现代处理器，如果连续输入可能会跟上。
@BCS：听起来您的第一步是运行 time(1) 并查看您正在使用的 CPU 比例。如果它很低，请尝试下一个弹出的东西。

标签： performance compression io

【解决方案1】：

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

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

如果您有一种算法可以将数据压缩 25% 以实现 125mb/s 的有效写入速度，那么每个字节您将有 24 个周期来运行它，并且它基本上是免费，因为在等待磁盘搅动时，CPU 无论如何都不会做任何其他事情。每字节 24 个周期 = 每 128 字节缓存线 3072 个周期，很容易实现。

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

如果您有空闲的第二个核心，那就更容易了。只需将日志缓冲区移交给该核心的线程，它可能需要尽可能长的时间来压缩数据，因为它没有做任何其他事情！唯一棘手的一点是您实际上希望拥有一圈缓冲区，这样您就不会让生产者线程（制作日志的线程）在互斥锁上等待消费者线程（将其写入磁盘的缓冲区）正在举行。

【讨论】：

【解决方案2】：

是的，至少 10 年都是如此。有关于它的操作系统论文。我认为 Chris Small 可能已经研究过其中一些。

就速度而言，gzip/zlib 较低质量级别的压缩相当快；如果这还不够快，您可以试试FastLZ。使用额外内核的一种快速方法是使用popen(3) 通过gzip 发送输出。

【讨论】：

开销是一个 fork 和 exec，这是相当重要的，所以如果只关心性能，它可能只在多核系统上值得做。另一方面，编程的简易性是无与伦比的，因此作为一个快速破解它值得在任何系统上进行。
我在考虑 IPC 开销。将 1GB 的数据塞入“|”需要多少成本？
我不知道这些天 I/O 库的优化程度如何。操作系统专家会知道。我的猜测是两个副本：从用户空间到内核空间并返回。由于压缩无论如何都需要接触每个字节，因此复制开销可能微不足道。不知道进程开销。

【解决方案3】：

Sun 的文件系统 ZFS 有能力启用动态压缩以减少磁盘 IO 量而不会显着增加开销作为实践示例。

【讨论】：

【解决方案4】：

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

结果取决于

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

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

在您的特定设置中，您应该尝试并测量。它确实可能会提高性能，但并非总是如此。

【讨论】：

【解决方案5】：

CPU 的增长速度比硬盘访问速度更快。甚至早在 80 年代，就可以从磁盘上读取许多压缩文件并在比读取原始（未压缩）文件所需的时间更短的时间内解压缩。这不会改变。

一般来说，现在压缩/解压缩处理的级别比您编写的要低，例如在数据库 I/O 层中。

至于第二个内核的有用性，只有在系统同时执行大量其他事情时才重要 - 并且您的程序必须是多线程的才能利用额外的 CPU。

【讨论】：

除非操作系统正在压缩磁盘，否则我 am 是最低级别（已编辑问题以反映这一点）。关于 2 个核心，我正在考虑让第二个核心完成所有压缩。

【解决方案6】：

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

【讨论】：

好点。 OTOH 我的大部分阅读都是在 diff 工具中完成的，以比较不同的运行（在什么时候运行 A 与 B 不同？）所以我需要一个可以在压缩流中读取的 diff 工具。二进制格式也可以区分，但会比较棘手。

【解决方案7】：

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

【讨论】：

【解决方案8】：

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

在您可用于此目的的 CPU 带宽的情况下，您能否将原始数据的压缩速度超过磁盘的原始写入性能乘以您正在实现的压缩率（或您尝试获得的速度倍数）？

鉴于当今 10 兆字节/秒的相对较高的数据写入速率，这是一个相当高的障碍。就其他一些答案而言，您可能必须拥有易于压缩的数据，并且只需要通过一些合理性测试类型的实验对其进行基准测试并找出答案。

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

【讨论】：

【解决方案9】：

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

【讨论】：

【解决方案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 也支持压缩分区。

【讨论】：

因此，对于一个快速的 HDD 和一个马马虎虎的 CPU，用压缩数据使磁盘饱和将充分利用大约一个核心。因此，如果我的磁盘不是那么好，或者我的 CPU 有点高端，或者如果我可以将压缩卸载到其他未使用的核心，我可以增加处理的未压缩数据量，并且仍然有一些 CPU 可用于生成数据第一名。
是的，这个粗略的估计告诉我，用压缩文本使快速 HDD 饱和将使用 2 GHz 核心的一半到全部，处理的未压缩文本量增加一倍。跨度>

【解决方案11】：

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

例如，共有 4 个磁盘的流行 RAID 1+0 配置可提供近 2 倍的加速。

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

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

另一方面，高压缩比显然不是那么简单。将“仅仅”6.30 压缩为 1 会为您打破当前的压缩世界纪录（Hutter 奖）提供现金奖励。

【讨论】：

【解决方案12】：

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

然而，正如 Shog9 所说：

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

【讨论】：

有趣。我想一旦您无法将压缩数据集保存在缓存中，它就会开始取决于您的 RAM 与 HDD 的速度。此外，HDD 是一个串行推管，因此它不应该受到太多延迟问题的影响。现代性能调整变得古怪。