I first noticed this behavior after migrating to 5.2.6.2, and I did
open a PMR with support. After several weeks of traces and more phone
calls than you can count, this is their official response...
Hi Kevin,
I have finished my review and, per our phone conversation, I believe I
know exactly what is causing this performance problem. The fix for APAR
IC45931 was introduced in the 5.2.6.2 level of TSM Server code (which
you are running) and part of this fix is to prevent our backup
optimization processing from invalidly skipping files on a volume which
have not been backed up. This is causing a performance problem in your
environment since we have to re-examine alot of the same files during
each backup stgpool run. This examination is done under a thread which
is not registered as a process which is why you see what appears to be a
hang after you issue the backup command. The extent of the performance
degradation is dependent on how many volumes are in the storage pool and
how many do not have current optimization entries. In your case, I would
say 80% of the volumes being analyzed are not current.
There is no true workaround for this but if any of these volumes are
written to again (forcing backup stgpool to process the volume), it will
force TSM to update the optimization. What I need to do is 1) find out
why the last volume entry that was written was not updated for
optimization purposes and 2) find out if we can somehow update the
optimization once we determine that we are out of sync. I will continue
to pursue these 2 points and will be discussing with our development
team. There is potential for an APAR in this condition but I want to
discuss with our development team before moving any further.
I will keep you posted on our findings. Let me know if you have any
questions.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Ben Bullock
Sent: Wednesday, December 28, 2005 12:47 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Stgpool backup behavior change in 5.3.x?
We too have seen this issue and I agree, it's annoying. It
behaves kinda like you put the "wait=yes" option on the command so that
it will not return the prompt until the command completes.
One of our foreign sites opened up a case with Tivoli about it,
but I have not heard what the outcome is. I will let you know if they
find anything out.
Since we are still at 5.2, I haven't had to battle that problem yet at
my location.
Ben
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Allen S. Rout
Sent: Wednesday, December 28, 2005 9:56 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Stgpool backup behavior change in 5.3.x?
I recently upgraded from 5.2.mumble to 5.3.2.1; In the intervening
weeks, I've noticed a behavior change which I don't see addressed in the
change notes.
I'm hoping for corroboration, and perhaps a comment from one of our
onlooking developers.
In 5.2, my user interaction looked like this:
1) Run BACKUP STGPOOL primpool copypool
2) New process appears in process listing
3) prompt returns
4) process looks for uncopied data, has status numbers of 0 files, 0
bytes
until it finds some. It might never find any, in which case it
reports
success, with 0 files, 0 bytes as additional information.
In 5.3, the following happens
1) Run BACKUP STGPOOL primpool copypool
2) prompt does not return
3) a process starts, not reflected in the process listing, and looks for
uncopied data.
4) if the process finds uncopied data, THEN:
4a) The prompt returns
4b) a process appears in the process listing, life goes on as before.
5) if the process does not find uncopied data THEN:
5a) The prompt returns with a ANR2111W, 'no data to process'.
5b) no process appears
I Can tell that 3) happens, because if I try to run another backup
stgpool, I get the conventional 'backup already in progress' message.
But it's not reflected in the process table. I have several servers
which take >8hrs to run a good stgpool backup, even if they do no new
copying work. That's a long time to have something going on behind the
scenes.
This block-the-command-flow behavior is really disruptive; the process
once started is declared as 'background', and WAIT still defaults to no.
But this is definitely a foreground process.
So: Do you-all share my impression here, and any IBMers want to
comment?
- Allen S. Rout
|
