快速压缩大量大文件

16

我每天产生约200 GB的日志数据，分布在约150个不同的日志文件中。

我有一个脚本将文件移动到临时位置，并在临时目录上执行tar-bz2。

将200 GB的日志压缩到大约12-15 GB后，我得到了很好的结果。

问题是压缩文件需要花费很多时间。该cron的工作上午2:30每天运行，并继续运行，直到5：00-6：00 PM。

有没有办法提高压缩速度并更快地完成工作？有任何想法吗？

不用担心其他所有过程，压缩发生的位置在NAS上，我可以在专用VM上运行将NAS挂载，然后从那里运行压缩脚本。

这是top的输出，以供参考：

top - 15:53:50 up 1093 days,  6:36,  1 user,  load average: 1.00, 1.05, 1.07
Tasks: 101 total,   3 running,  98 sleeping,   0 stopped,   0 zombie
Cpu(s): 25.1%us,  0.7%sy,  0.0%ni, 74.1%id,  0.0%wa,  0.0%hi,  0.1%si,  0.1%st
Mem:   8388608k total,  8334844k used,    53764k free,     9800k buffers
Swap: 12550136k total,      488k used, 12549648k free,  4936168k cached
 PID  USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 7086 appmon    18   0 13256 7880  440 R 96.7  0.1 791:16.83 bzip2
7085  appmon    18   0 19452 1148  856 S  0.0  0.0   1:45.41 tar cjvf /nwk_storelogs/compressed_logs/compressed_logs_2016_30_04.tar.bz2 /nwk_storelogs/temp/ASPEN-GC-32459:nkp-aspn-1014.log /nwk_stor
30756 appmon    15   0 85952 1944 1000 S  0.0  0.0   0:00.00 sshd: appmon@pts/0
30757 appmon    15   0 64884 1816 1032 S  0.0  0.0   0:00.01 -tcsh

— 阿努
source

2

如果您有多个CPU，并且拥有或可以将其拆分为多个tar文件，则可以运行多个压缩。

— 杰夫·谢勒

@JeffSchaller是否有可能使多个bzip2进程压缩不同的文件但写入同一tar.bz2文件？

— 2016年

2

在移至NAS之前是否在本地磁盘上生成了日志文件？如果这样压缩，然后移动；这样，压缩时您仅通过网络发送15Gb数据，而不是100（移动），然后发送115（100read + 15write）。或者，看起来您可能受那个bzip2进程的CPU约束，因此并行运行多个（每个CPU一个）可能会有所帮助（直到达到I / O限制）。或者使用更简单的压缩方式（例如“ gzip -1”）。它不会节省那么多磁盘空间，但运行速度更快。

— 史蒂芬·哈里斯

@Sukminder我一定会尝试一下，看看大小上的差异。谢谢。

— 阿努

您的top输出显示单线程bzip2进程正在用尽一个内核，但是您正在四核系统上运行它（一个进程使用100％CPU-> 25.1%用户空间CPU时间，其中74％处于空闲状态）。因此，只需进行较小的更改，您就可以以4倍的速度运行，除非其他因素成为瓶颈。阅读吉尔斯仔细回答。考虑在与容纳数据的磁盘相同的框中使用CPU进行压缩。（您甚至可以将一些文件压缩在一个盒子上，而另一些文件则压缩在另一个盒子上，然后再存档，因此两个CPU都可以使用。）

— Peter Cordes

25

第一步是弄清楚瓶颈是什么：磁盘I / O，网络I / O还是CPU？

如果瓶颈是磁盘I / O，则您无能为力。确保磁盘不会处理许多并行请求，因为这只会降低性能。

如果瓶颈是网络I / O，请在存储文件的计算机上运行压缩过程：仅在CPU瓶颈的情况下，在CPU功能更强的计算机上运行压缩过程。

如果瓶颈是CPU，那么首先要考虑的是使用更快的压缩算法。Bzip2不一定是一个不好的选择-它的主要缺点是解压缩速度-但是您可以使用gzip并牺牲一些大小来提高压缩速度，或者尝试其他格式，例如lzop或lzma。您可能还调整了压缩级别：bzip2默认为-9（最大块大小，因此最大压缩，但是最长压缩时间）；环境变量设置BZIP2为一个值喜欢-3尝试压缩级别3. 此线程和这个线程讨论共同的压缩算法; 特别是本博客文章由derobert列举了一些基准，这表明，gzip -9或者bzip2与相比，的水平较低可能是一个不错的折衷方案bzip2 -9。另一个基准其中还包含lzma（7zip的算法，因此您可以使用7z代替tar --lzma）表明lzma在较低级别可以更快地达到bzip2压缩率。除了bzip2以外，几乎任何其他选择都会缩短解压缩时间。请记住，压缩率取决于数据，压缩速度取决于压缩程序的版本，编译方式以及在其上执行的CPU。

如果瓶颈是CPU并且您有多个内核，那么另一个选择是并行化压缩。有两种方法可以做到这一点。适用于任何压缩算法的一种方法是分别（分别或成组）压缩文件，并用于parallel并行运行归档/压缩命令。这可能会降低压缩率，但会加快单个文件的检索速度，并可以使用任何工具。另一种方法是使用压缩工具的并行实现。这个线程列出了几个。

— 吉尔斯“别再邪恶了”
source

4

“如果瓶颈是磁盘I / O，那么您无能为力。” 因为压缩率已经很好，所以这里可能是正确的，但是通常在I / O成为瓶颈时，值得花更多的时间来使用CPU以获得更好的压缩率（使用不同的压缩设置或不同的算法）。 ..您不能真正减少“ I”（因为您需要读取所有数据），但是有时可以显着减少“ O” :-)

— psmears

1

如果您告诉您7z不要建立“实体”归档文件，或者不限制“实体”块的大小，它将在IIRC上并行运行多个LZMA线程。日志文件数据是压缩的一种特殊情况，因为它往往是高度冗余的（行之间有很多相似之处）。这是绝对值得的测试gzip，bzip2以及xz对OP的具体日志文件，而不是只盯着通用压缩基准，以排除任何选项。即使是最快的压缩机是值得考虑的（lzop，lz4，snappy）。

— 彼得·科德斯

这些天首选的LZMA压缩机是xz。使用tar -J或--xz，而不要使用--lzma。 .lzma被认为是“旧版”文件格式。用于LZMA压缩的文件格式的多次迭代有些尴尬，这是他们第一次应该正确的做法。但是AFAIK现在基本上很好，并且.xz不会被同一压缩流的另一种文件格式替代。

— 彼得·科德斯

7z确实具有出色的压缩和多线程功能，但是由于存档格式（需要索引，或者可能是错误？），我认为它不能在管道中间使用-它不会使用stdin 和 stdout同时

— Xen2050 '16

这真的很有帮助，很有见识。我的团队认为，通过NFS进行操作是一个很大的瓶颈。

— 2016年

16

您可以安装pigz，并行gzip并将tar与多线程压缩一起使用。喜欢：

tar -I pigz -cf file.tar.gz *

其中的-I选项是：

-I, --use-compress-program PROG
  filter through PROG

当然，如果您的NAS没有多个内核/强大的CPU，那么无论如何，您都会受到CPU能力的限制。

VM和压缩正在其上运行的硬盘/阵列的速度也可能成为瓶颈。

— 马兹
source

1

如果要使用bzip2，则可以使用pbzip2或lbzip2。

— 拉多万·加拉比克（RadovanGarabík），2013年

2

这是您最好的答案。但是首先，请确保您的第一个举动是与原始文件位于同一文件系统上的位置。否则，您的“移动”实际上是一个字节复制然后删除。在同一文件系统上，移动是对文件系统链接的重新排列。这快了几个数量级。对于我的数百GB的日志文件，pigz发挥了所有作用。您可以告诉它要运行多少个并行线程。只要您的CPU具有多个核心，我就不会花费很多时间进行调查。无论如何，您可能都希望pigg。您可以立即提高速度。

— Mike S

整理之后，如果您想进一步调查系统，请查看htop和iostat输出并观察系统性能。但是再次，我将不再尝试在没有Pigz的情况下压缩大文件。在现代多核系统上，不使用它是很愚蠢的。这是一个立竿见影的胜利-您将看到。

— 迈克S

7

到目前为止，压缩数据的最快，最有效的方法是生成更少的数据。

您生成什么样的日志？每天200GB的声音听起来很多（除非您是google或某些ISP ...），请考虑1MB的文本大约为500页，因此，您每天产生的文字数量相当于1亿页，一周内填满国会图书馆。

查看日志数据是否可以通过某种方式减少并仍然从日志中获得所需的信息。例如，通过降低日志级别或使用更短的日志格式。或者，如果您正在使用日志进行统计，则可以即时处理统计信息并转储带有摘要的文件，然后在压缩进行存储之前过滤日志。

— 艾米莉·L
source

1

这是一个有趣的哲学解决方案。解决大多数生活问题的方法是完全避免出现问题。直到有人仔细研究了该建议，然后才意识到要实现这一目标，必须经过数百人和数千人的批准。

— 2016年

1

@anu没有给出问题的上下文，因此我认为没有任何上下文。您能告诉我您从哪里获得1000份批准书吗？在我看来，您似乎已经做好了。

— 艾米莉·L。

我会投票赞成。这是经常被忽视但又被人们注意到的解决生活中许多问题的出色解决方案。

— jrw32982

1

好吧..现在我不再在那里工作了，我至少可以透露这是苹果公司的问题。更具体地说，是在为在线应用程序商店提供服务的服务堆栈上...因此，是的，这实际上是成千上万的批准，因为它们具有1000的微服务，并且每个微服务都会生成需要压缩的日志，并且必须在更改其日志时进行签名日志记录级别等...无论如何...我们为这个内部btw找到了一个解决方案。

— 阿努

3

您可以减少压缩量（就节省的空间而言）以使其更快。首先，bzip2比gzip慢很多，尽管它压缩得更小。您还可以更改bzip2，gzip或大多数压缩程序的压缩级别，以权衡速度。

如果您不愿意权衡速度的大小，则仍然可以使用使用LZMA（例如xz）的压缩器来获得相同大小或更小的尺寸，同时仍然可以提高速度。

您可以通过搜索找到基准，但是最好的选择是对目标硬件上的文件进行一些测试。

— 埃里克
source

3

如果唯一的要求是压缩为 速度快，我会非常推荐lz4。

它用于很多地方，压缩的速度比压缩率更重要（例如，具有透明压缩的文件系统，例如ZFS）

— do
source

以前从未听说过它，是否有可能已经在几乎所有使用它的地方（例如xz）安装了一个程序？

— Xen2050 '16