HPUX 11.00: Ignite UX 4.1.61 "make_recovery" , "make_tape_recovery" Running Very Slow

[LG Porter]

I have two K580 servers running HPUX 11.00 in a MCSG configuration. I have recently been experiencing problems with the "make_recovery" or "make_tape_recovery" taking a very long time to complete.....6 to 10 hours? Is there any known issues to date regarding this issue? I have cleaned the tape drive, switched out brand new tapes as well as upgraded to the most recently version of Ignite-UX 4.1.61. (Previously had a older version of Ignite-UX 3.2.45 installed however the HP Response Center requested that the version be upgraded to the most recent. Until recently, the older version had worked great.Prior to this problem, a make_recovery would complete successfully in about 1.5 hrs..) Is there any known issues as to why a "make_recovery" tape would take this long to complete?

[Steven E. Protter · Accepted solution]

Ignite is doing a lot of operations with pax, packing up files then gzipping them.

Could it be that your data has increased somewhere thats included in the make_tape_recovery?

That is the only thing thats ever caused my make_tape_recovery times to balloon.

Except when one of my CPU's decided to go on holiday. That slowed it down too.

SEP

[Elena Leontieva]

Check out this, just in case ...
Document description: make_tape_recovery normally takes 20 minutes, now takes 90 minute
Document id: UIUXKBRC00011662

[Pete Randall]

Hi,

What command line are you using to initiate your make_tape_recovery? Are you including just vg00? Has vg00 experienced any substantial growth? If other VG's are involved, have they grown?


Pete

[John Poff]

Hi,

I'd check to make sure you have the latest pax patches installed. Also, if you have Glance available, take a look at the processes and see what they are doing. Maybe you can see what they are blocked on.

JP

[Steven E. Protter]

I would not have the latest pax patch.

At least if thats PHCO_26422 (11.11). That patch gives pax the ability to bpack files between 2-8 GB. Problem with that is that pax_iux the utility that unpacks archives can't unpack files that big.

So, in general pax patches are okay, so long as you are careful to avoid the one I just noted.

SEP

[yogesh_4]

There can be two possibilities either your VG00 size is increased or you can clean your DAT drive and then see the performance.

[Bruno Vidal]

Hi,
I'll recently have this kind of pb, take care if you are excluding files. It use a temporary file named /var/tmp/exclude.temp, and it is never cleaned, So it can grow a lot, and scanning throught this file can be really time consuming. So before doing your tape, try to remove this file (it is recreated).

Cheers.

[Buddy Mohmedi]

A couple of points to consider.

1. It is adviseable to use make_tape_recovery as make_recovery will be made obsolete in the future. Better to migrate now than later.

2. You have not supplied any details about the exact command you are using or the type of tape drives.

3. Check to see where the make_tape_recovery is spending all its time.

- Get the output of "UNIX95=1 ps -efH" and find the make_tape_recovery command and all its children. Repeat the command several times over 5 minutes and determine if the CPU time increases or if the list of processes change. Something may be slowing things down!!!

- Use glance (if available) to see if the last process in the list from above is doing something. Look at the system calls being made and at the blocked reason.

- Check to see if the tape is getting written to over a 5 to 10 minute period. If the tape drive is not streaming, the make_tape_recovery will be slow!

- Has the size of the archive changed or are you including other volume groups. Maybe your system has a few crash dumps that are being included.

- If you use something like PRM or WLM, ensure the ignite process is running in a process group that has enough resources.

- Is your system under memory pressure?


Hope this helps.


Cheers.

[Tim D Fulford]

I found in general K classes take longer to ignite than say L calsses. One of the reasons I believe was that the tape is slow (DDS1), I tried on DLT and this sped things up some.

The other problem you MAY be having is that you are experiencing a disk bottleneck, thus the data is not able to get off your disk quick enough. What is you CPU & load level when running ignite? If cpu relatively low & load level relatively high you have a probable bottleneck (may be disk?)

Tim