AIX

Hi, I am currently looking at how we can optimize and speed up our backups here. I am just a beginner operator and our system admin hardly knows anything (long term interim).

There is this particular TAR backup of DB backups that for a 10.5Gb amount of files, it takes 5 hours to do the backup on 5Gb tapes. For all our DB to be backed up and verified on tapes, it takes over a normal day shift (10 DB where 2 DB per servers and one tape drive per server).

I checked the drive and compression is ON. Sine we are on a 4.2 AIX, our TAR does not have compression options. I did a test where using compress, I managed to compress a 1.9Gb file that took 25min on disk.

What would you suggest checking to see what can be optimized/speeded up ?

I will be going on to work in 1.5hr (currently 17:30). So from there I could reply back with whatever infos you guys need (you may have to indicate how to get it first).

If you have a multiprocessor machine (which is most likely when you have a database server) you could do the following: pipe the output of tar to a gzip process, like the following command:

Code:

tar -cvf - <file-list> | gzip -9 > /some/file

The problem is the following: gzip is a single-threaded process (naturally). If you only issue the command as shown above you would use one single processor and the rest of the processing power would be idle.

Therefore you will have to determine the file sizes of the files to be backed up before and create as many instances of this process as you have processors, where you distribute the files as equally as possible and run these processes in parallel. This would utilize all the processors in your system and probably (since compressing is the most work-intensive task) drastically reduce the backup time. The following is a sketch of such a script:

Code:

no_of_procs=5
files[1]="file1 file2 file3"
files[2]="file4 file5 file6"
files[3]="file7 file8 file9"
files[4]="file10 file11 file12"
files[5]="file13 file14 file15"

(( i = 1 ))
while [ $i -le $no_of_procs ] ; do
     tar -cvf - ${files[$i]} | gzip -9 > backup.part${i} &
     (( i += 1 ))
done

If you have enough free file space write the backups to disk first (this is faster) and only write these files to tape. Your backup will in fact be done when the files are written to disk and it will not matter how long it takes to shuffle them off to tape.

I hope this helps.

bakunin

Thank you for the info.

Unfortunetly, we have gzip (v1.2.4) on 1 of the DB servers. I am not aware of the license related ot its usage. So I cannot copy it over to the other DB servers.

The only compress tool we have across all servers is 'compress'.

However, if compress is a one single-threaded process, then the same method could be applied. So instead of taking 2hrs to compress all files of one DB backup, it would in theory take 20-30 min in total.

One other question, in using 'compress', which temporary storage does it use while compressing the file ? The current or some other assigned system folder ?

The folder where the backups are is pretty full and since I am not the system admin, I cannot increase its space.

gzip is short for GNU-zip und released under the GNU public license. Copy, distribute or reprogram it as much as you like (in principle - see the GPL for details).

I do know know the intrinsics of compress, but i suppose it will work similar to gzip. The Lempel-Ziv-Welch algorithm uses a relatively small codebook which is stored in memory therefore no intermediate files are necessary. The wiki-article about the LZW-algorithm is a good start if you are interested.

In principle you are correct, you could use compress instead of gzip with about the same result.

I hope this helps.

bakunin

How do I find out how many processors it has ?

The only physical docs we have here is about the company's applications, not the system.

Some ways:

Code:

lsdev -C| grep proc| grep -c available
lsconf| grep "Number of Processors"
prtconf| grep "Number of Processors"
lparstat -i
# or also check your hmc if it is a LPAR

Crap !

When checking this, it says it only has ONE processor !!!!

That sort of crashes what I wanted to do : using one compress command in background per processor to gain time

I will have to find another way.