当我使用tar/gzip时，我做了大量的备份，这给我的服务器带来了巨大的压力。 我有任务设置作为一个cronjob访问我的脚本，处理备份。 我知道，在这种情况下， nice可能会有所帮助，但是我对使用它的正确方式有些不确定。
我的脚本中有以下命令：
tar -cf gzip -9
我只需要在它前面添加nice命令就可以减less优先级？
nice -n 13 tar -cf nice -n 13 gzip -9
有没有使用这种方法的警告？ 谢谢。
有一些注意事项需要注意。 由于这个问题没有指定一个确切的操作系统（但暗示它是一些类似于操作系统的Unix），所以需要注意的是操作系统和版本。 要记住的最重要的是：
nice的意图是影响给一个进程多lessCPU时间，而不是多lessRAM或I / O容量。 因此，而不是预期的效果，其他可能的结果包括：
nice的使用完全没有任何作用，因为备份过程是I / O绑定的开始，I / O调度不受nice影响。 如果操作系统恰好是最新的Linux版本，则根据所使用的ionice设置，I / O调度可能会受到影响，也可能不会受到影响。 而且，即使对CPU调度的确切影响也取决于具体的操作系统和设置。 一些内核具有的设置将允许进程以比使用nice命令可达到的优先级更高或更低的优先级运行。
我遇到的一个警告似乎是Ubuntu 14.04特有的。 在默认configuration中，它将进程分组以用于调度目的。 每个小组然后收到一个公平份额的CPU时间。 nice只影响CPU时间如何分配给这个组内的进程，而不是分配给每个组多less。 对我来说，完全破坏了nice使用，因为低优先级的进程仍然可以从不同组中的进程中消耗CPU时间。
我会采取一种不同的方法…
不，我不会为此而烦恼。 而gzip并不是那么好。 另外，你正在使用gzip -9 ，它以CPU为代价提供了最大的压缩率。 你真的需要在默认级别（级别6）的压缩级别？
如果你不使用gzip级别9，你的系统是否会变得紧张？
你的服务器的规格是什么？ 你有多less种types的CPU？ cat /proc/cpuinfo
如果你有多个CPU，你会考虑使用pigz吗？ 它是multithreading的，效率更高，可以更好地利用系统上的资源。
一些1.8GB文件的testing：
标准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（最高压缩率，multithreading）
Original file size: 1.8G CHL0001.TXT Compression time: 0m5.611s Compressed file size: 76M CHL0001.TXT.gz Decompression time: 0m2.489s
结论：压缩额外的压缩比数据压缩更长的时间是否值得？
我意识到这是偏离原来的问题，但它仍然停留在效率的主题（你提到“我的服务器上的巨大压力”）…
我推断（或猜测！）从你已经发布，你正在创build一个包含一组文件，然后gzip的结果。 您可以通过将一个pipe道直接连接到另一个pipe道来节省大量磁盘I / O（和临时空间需求）：
tar cf - /path/to/stuff | gzip > archive.tar.gz
你可能会发现这对总的时间有很大的影响。