代码之家  ›  专栏  ›  技术社区  ›  BCS

压缩以提高硬盘写入性能

  •  9
  • BCS  · 技术社区  · 16 年前

    在现代系统中,压缩输出流可以提高本地硬盘的写入速度吗?

    这个问题源于我正在处理的一个案例,在这个案例中,一个程序连续地生成和转储大约1-2GB的文本日志数据到硬盘上的一个原始文本文件,我认为它是IO绑定的。我希望能够在数据进入磁盘之前通过压缩数据来减少运行时间,还是压缩开销会消耗掉我所能得到的任何收益?有一个空闲的第二核心会影响这一点吗?

    我知道这会受到多少CPU被用来生成数据的影响,所以关于需要多少空闲CPU时间的经验法则是好的。


    我记得有人用压缩来提高数据库的读取速度,但iirc压缩比解压缩要占用更多的CPU。

    12 回复  |  直到 9 年前
        1
  •  1
  •   Tall Jeff    16 年前

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

    考虑到您为此目的提供的CPU带宽,压缩原始数据的速度能否比磁盘的原始写入性能乘以压缩比(或尝试获得的速度倍数)?

    考虑到目前10兆字节/秒的数据写入率相对较高,这是一个很高的障碍。就其他一些答案而言,你可能需要有容易压缩的数据,并且只需要用一些合理性测试作为基准,然后找出答案。

    相对于一个特定的意见(猜猜看!?)关于附加核心。如果您对数据的压缩进行线程化,并保持核心的支持——文本的高压缩比,那么这种技术很可能会产生一些效果。但这只是一个猜测。在一个单线程应用程序中,在磁盘写操作和压缩操作之间交替进行,在我看来,这种可能性要小得多。

        2
  •  7
  •   Crashworks    16 年前

    是的,是的,是的,绝对的。

    这样看:以每秒兆字节为单位计算最大连续磁盘写入速度。(继续测量,计时一个巨大的FWRITE或其他东西。)假设100MB/s。现在以兆赫为单位计算CPU速度;假设3GHz=3000兆赫。将CPU速度除以磁盘写入速度。这是CPU空闲的周期数,您可以使用 每字节 压缩时。在这种情况下,3000/100=每字节30个周期。

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

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

    如果你有一个空闲的第二核心,那就更容易了。只需将日志缓冲区交给该核心的线程,它就可能需要压缩数据的时间,因为它不做任何其他事情!唯一棘手的一点是,您希望实际拥有一个缓冲区环,这样您就不会让生产者线程(生成日志的线程)等待一个互斥对象来获取消费者线程(将其写入磁盘的线程)正在保存的缓冲区。

        3
  •  4
  •   Norman Ramsey    16 年前

    是的,至少10年来都是这样。有关于它的操作系统论文。我想克里斯·斯莫尔可能对其中一些人有所帮助。

    为了速度, gzip / zlib 低质量级别的压缩速度相当快;如果速度不够快,可以 尝试 FastLZ . 使用额外核心的快速方法就是 popen(3) 通过发送输出 GZIP .

        4
  •  3
  •   adamJLev    16 年前

    值得一提的是,Sun的文件系统zfs能够动态压缩以减少磁盘IO量,而不会显著增加开销,这在实践中就是一个例子。

        5
  •  3
  •   dmeister    15 年前

    这个 Filesystems and storage lab from Stony Brook 在服务器系统上发布了一个相当广泛的文件数据压缩性能(和能量)评估 IBM's SYSTOR systems research conference 今年: paper at ACM Digital Library , presentation .

    结果取决于

    • 使用压缩算法和设置,
    • 文件工作负载和
    • 机器的特性。

    例如,在本文的度量中,使用文本工作负载和服务器环境 低压缩工作的lzop比普通写快,但是bzip和gz不是 .

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

        6
  •  2
  •   Alister Bulman    16 年前

    CPU以比硬盘访问更快的速度增长。即使回到80年代,也可以从磁盘上读取许多压缩文件,并在比读取原始(未压缩)文件所用的时间更短的时间内进行解压缩。不会改变的。

    不过,通常情况下,这些天的压缩/反压缩处理的级别比您要写的级别低,例如在数据库I/O层中。

    至于第二个核心的有用性,只有当系统还将做大量其他事情时才有意义——而且您的程序必须是多线程的才能利用额外的CPU。

        7
  •  2
  •   Mark James    16 年前

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

        8
  •  2
  •   codymanix    16 年前

    Windows已经支持在NTFS中进行文件压缩,所以您所要做的就是在文件属性中设置“compressed”标志。 然后你可以测量它是否值得。

        9
  •  1
  •   Joachim Sauer    16 年前

    如果只是文本,那么压缩无疑会有所帮助。只需选择一种压缩算法和使压缩变得便宜的设置。”gzip“比bzip2便宜,并且两者都有参数,您可以调整以支持速度或压缩比。

        10
  •  1
  •   community wiki David Cary    14 年前

    如果您是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也支持压缩分区。

        11
  •  1
  •   community wiki David Cary    14 年前

    如果这台机器经常是IO绑定的, 另一种加快速度的方法是安装一个RAID阵列。 这将使每一个程序和每一种数据(甚至是不可压缩的数据)都加速。

    例如,流行的RAID1+0配置总共有4个磁盘,其速度提高了近2倍。

    几乎与流行的RAID5配置相同,共有4个磁盘,使所有配置的速度提高了近3倍。

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

    另一方面,高压缩比显然不是那么简单。将“仅仅”6.30压缩为1将给你一个打破当前压缩世界纪录的现金奖励(Hutter奖)。

        12
  •  0
  •   community wiki Michael Burr    16 年前

    这曾经是可以在相当多的应用程序中提高性能的东西。我想今天它不太可能有回报,但在您的特定情况下,尤其是当您记录的数据很容易压缩时,

    然而,正如Shog9所说:

    经验法则没用 你在这里。这是你的磁盘,你的CPU, 还有你的数据。设置测试用例并 测量吞吐量和CPU负载 没有压缩-看看是不是 值得权衡。