I'd take a different approach...
No, I wouldn't mess around with nice
for this. And gzip
isn't that great. Plus, you're using gzip -9
which gives the greatest compression rates at the expense of CPU. Do you really need that level of compression over the default (level 6)?
Does your system get strained as much if you don't use gzip level 9?
What are the specifications of your server? How many and what type of CPUs do you have? cat /proc/cpuinfo
If you have multiple CPUs, would you consider using pigz
instead? It's multithreaded, a bit more efficient and can leverage the resources on your system much better.
Some tests with a 1.8GB file:
Standard gzip
(-6 compression level)
Original file size: 1.8G CHL0001.TXT
Compression time: 0m18.335s
Compressed file size: 85M CHL0001.TXT.gz
Decompression time: 0m6.300s
gzip -9 (highest compression)
Original file size: 1.8G CHL0001.TXT
Compression time: 1m29.432s
Compressed file size: 75M CHL0001.TXT.gz
Decompression time: 0m6.325s
pigz (-6 compression level)
Original file size: 1.8G CHL0001.TXT
Compression time: 0m1.878s
Compressed file size: 85M CHL0001.TXT.gz
Decompression time: 0m2.506s
pigz -9 (highest compression, multithreaded)
Original file size: 1.8G CHL0001.TXT
Compression time: 0m5.611s
Compressed file size: 76M CHL0001.TXT.gz
Decompression time: 0m2.489s
Conclusion: Is the extra bit of compression worth the vastly longer time spent compressing the data?
nice
? You will schedule all the backup process. Checkionice
command too.ionice
, so I'll have to check it out. The script gets called by a cronjob - so would I just append that within crontab? for example:30 22 * * * /bin/sh nice -n 13 myscript.sh
. I'm also not sure, but if I did this within the script wouldn't the secondnice
affect the first one? meaning that gzip is a sub-process of tar?tar
andgzip
after, thenice
will affect the script and all child process.* * * * * /usr/bin/nice -n 13 ...
- so would I not use/usr/bin/sh
?