Dataprotector backup, 2 bound CPU's, 6 drives = high load

[Richard I Curtis]

I have a vpar with 2 bound CPUs which normally sits at a load average of about 0.7
When I kick off a dataprotector backup, the load climbs to 10 and stays there until the backup ends. There are 24 filesystems being backed up in paralell to 6 drives to get best throughput, but I think this is the cause of the high load...

My theory is that we have 6 disk agents trying to do very heavy IO, but as we have only 2 bound CPU's available to handle that IO, we are constantly switching between the 6 disk agent processes, and the other application processes. Switching to 2 drives max gives a load of around 2.2 which is sustainable, but is there anything else I can look to tuning to allow both good system response/low load, but also use more than 2 drives?

Does my theory sound feasible?

[Paul McCleary]

Hi Richard,

You don't mention the amount of data you are backing up and what throughput you are getting to the drives.

What type of drives are they and how are they connected?

What system is it and what processors do you have?

Also, what is the difference in backup time between having 6 drives and 2 drives?

At first glance I think you are asking far too much of a 2 CPU vPar to drive 6 tape drives at full speed.

If these are SAN drives, maybe you could find another server to share the load and run some of these backups so you can complete in the shortest possible time?

Hope this helps,
Paul

[Emil Velez]

If they are 6 LTO drives on different FC busses these tape drives will write very very fast and you want that. YOu may want to go into your session reports and look at how many GB per hour you are writing.

If you really want some CPU to be allocated to other processes on the box you can use PRM to allocate a limited amount of cpu to the vbda and mma processes. that way other things will have CPU to run

[Richard I Curtis]

I hadn't checked the actual speed to tape, but having looked, it is the same gb/min whether I use 2 or 6 drives. The fibre cards should be more than capable (two 1gb fibres) so I guess that the limitation is the number of bound CPU's.

I'll keep the jobs running with two drives until I can get some more CPU's licensed.

Thanks for the replies!

[Chris Vail]

You WANT your processor loads at 90% or more when making backups. If the system is running at less than 90% of capacity, you should re-allocate system resources to other applications until it is.

If the backup time is not fast enough, add processor resources and memory. If the light pipes fill up, add light pipes. If the tapes can't handle the load, add tapes. HPUX hardware does 'play well with others' and the more assets available, the faster the system will be.

Of course, this is all very expensive...but even MORE expensive is not having a backup when it is needed.

In my experience, making backups (regardless of software) is one of the few times you can throw processor and memory resources at a problem and make it go faster.

Years and years ago I found this out...the same physical tape drive ran at about double the throughput when I moved it to a faster machine. Tape devices and SCSI channels do respond nicely to faster/wider CPU's.

[Bill Hassell]

It should be noted that the newer LTO drives have VERY high requirements on CPU and disk speeds to even come close to the tape speed. The LTO-4 needs 120 MB/sec MINIMUM with no compression, more than 240 MB/sec to keep up with the compression inside the tape drive. This is not possible in smaller systems so the high performance LTO drives have a data rate matching system to slow the drives down to as little as 30 MB/sec.

This is a *LOT* of data and Data Protector will do everything it can to keep ahead of the tape drive. If the drive is starved for data, it will halt, backup and try again once more data arrives. This restart sequence devastates throughput and wears heavily on both tape and drive. So you can certainly expect a very high load -- there's a lot of work to do. You can reduce the load somewhat by only backing up large files (ie, larger than 100 megs).