在 tar/gzip cron 脚本中使用良好的调度优先级

Question

我做了大量备份，在使用tar/gzip. 我已经将任务设置为一个 cronjob，它访问我处理备份的脚本。我知道这nice在这种情况下可能会有所帮助，但我不确定使用它的正确方法。

我的脚本中有以下命令：

tar -cf 
gzip -9 

我nice会像这样在它前面添加命令以降低优先级吗？：

nice -n 13 tar -cf 
nice -n 13 gzip -9

使用这种方法有什么注意事项吗？谢谢。

Answer 1

有一些注意事项需要注意。由于问题没有指定确切的操作系统（但暗示它是一些类似 Unix 的操作系统），因此警告列表将取决于特定的操作系统和版本。要记住的最重要的是：

nice旨在影响分配给进程的 CPU 时间，但不影响 RAM 或 I/O 容量。因此，除了预期效果之外，其他可能的结果包括：

• 由于分配的 CPU 时间较少，因此备份需要更长的时间才能完成。但是它将使用与以前一样多的 RAM，现在它将使用该 RAM 的时间更长。由于用于其他用途的 RAM 较少，系统速度变慢，并且这种速度变慢将比以前持续更长的时间。
• 使用nice完全没有影响，因为备份过程开始是 I/O 绑定的，并且 I/O 调度不受nice. 如果操作系统恰好是最近的Linux版本中，I / O调度可能会或可能不会受到影响nice，这取决于ionice正在使用的设置。

此外，甚至对 CPU 调度的确切影响在很大程度上取决于特定的操作系统和设置。某些内核具有允许进程以比使用该nice命令可达到的优先级更高或更低的优先级运行的设置。

我遇到的一个警告似乎是针对 Ubuntu 14.04 的。在默认配置中，它出于调度目的对进程进行分组。然后，每个组都会获得公平的 CPU 时间份额。nice仅影响 CPU 时间如何分配给此类组内的进程，而不影响分配给每个组的时间。对我来说，这完全破坏了 的使用nice，因为低优先级的进程仍然可以从不同组的进程中占用 CPU 时间。

Answer 2

我会采取不同的方法...

不，我不会为此而胡思乱想nice。而且gzip不是很大。另外，您正在使用gzip -9它以牺牲 CPU 为代价提供最大的压缩率。您真的需要比默认值（级别 6）更高的压缩级别吗？

如果您不使用 gzip 级别 9，您的系统是否会变得紧张？

你的服务器规格是多少？你有多少和什么类型的 CPU？cat /proc/cpuinfo

如果您有多个 CPU，您会考虑使用它pigz吗？它是多线程的，效率更高，并且可以更好地利用系统上的资源。

一些 1.8GB 文件的测试：

标准gzip（-6 压缩级别）

Original file size: 1.8G    CHL0001.TXT 
Compression time: 0m18.335s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m6.300s

gzip -9（最高压缩率）

Original file size: 1.8G    CHL0001.TXT
Compression time: 1m29.432s
Compressed file size: 75M   CHL0001.TXT.gz
Decompression time: 0m6.325s

pigz（-6 压缩级别）

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m1.878s
Compressed file size: 85M   CHL0001.TXT.gz
Decompression time: 0m2.506s

pigz -9（最高压缩，多线程）

Original file size: 1.8G    CHL0001.TXT
Compression time: 0m5.611s
Compressed file size: 76M   CHL0001.TXT.gz
Decompression time: 0m2.489s

结论：额外的压缩是否值得花费更长的时间来压缩数据？