anu*_*anu 16 tar shell-script bzip2 optimization
我每天生成大约 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
Gil*_*il' 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并行运行存档/压缩命令。这可能会降低压缩率，但会提高单个文件的检索速度并适用于任何工具。另一种方法是使用压缩工具的并行实现；这个线程列出了几个。
maz*_*azs 17
您可以安装pigz、并行 gzip，并将 tar 与多线程压缩一起使用。喜欢：
tar -I pigz -cf file.tar.gz *
-I选项在哪里：
-I, --use-compress-program PROG
filter through PROG
当然，如果您的 NAS 没有多核/强大的 CPU，那么您无论如何都会受到 CPU 能力的限制。
运行虚拟机和压缩的硬盘/阵列的速度也可能是一个瓶颈。
你生成什么类型的日志？每天 200GB 听起来很多（除非你是 google 或某些 ISP...），考虑到 1MB 的文本大约是 500 页，所以你每天生成相当于 1 亿页的文本，你会在一周内填满国会图书馆。
查看您的日志数据，如果您可以以某种方式减少它并仍然从日志中获得您需要的内容。例如，通过降低日志级别或使用更简洁的日志格式。或者，如果您使用日志进行统计，请即时处理统计信息并转储带有摘要的文件，然后在压缩存储之前过滤日志。