what is your maintenance level of AIX 5.1 on the client?

At 03:04 AM 7/11/2003 +0300, you wrote:

Few comments:
--> TCPWindowsize         1048576
As per the Admin Guide "You can specify a value from 0 to 2048"! It is in
kilobytes, not in bytes.

--> Virtualnodename client:
--> Both clients have
To best of my knowledge when you use -virtualnodename options are not read
from dsm.sys/dsm.opt but their defaults are used instead. I would be happy
to be proved wrong.

Zlatko Krastev
IT Consultant






"Conko, Steven" <sconko AT ADT DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
07.07.2003 22:08
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Re: Restore slows to a crawl


Thanks. I'll try to provide as much information as I can. If I dont
provide
enough please let me know.

Server: AIX 4.3.3, TSM 5.1.5
Client: AIX 5.1, TSM 5.1.5.4
Virtualnodename client: AIX 5.1 TSM 5.1.5.4

collocation is turned off. compression is off. maxnummp for both nodes is
set to 6. we are using a 3494 tape library with 12 3590 tape drives. node
disk storage is on an IBM ESS. the backup/restore LAN is gigabit. system
'A'
was backed up to tape from 1 mount point. i am attempting to restore to
system 'B' over 4 mount points. all filesystems are of type jfs2. nothing
else is running on the TSM Server.

Settings on TSM Server:
TCPWindowsize         1048576
TCPBufsize            32768
CommTimeOut           999
IdleTimeOut           60

Both clients have:
Keep Mount Point = Yes
largecommbuffers   yes
resourceutil       10
compression        yes
tcpnodelay         yes
tcpbuffsize        32
tcpwindowsize      64
txnbytelimit       2097152

since the restore is going to 4 separate mount points, i started four
separate restores, broken down by destination mount point. The restores
appear to begin running fine. Then at some seemingly arbitrary point, a
session will suddenly slow to a crawl while in the middle of restoring a
file... it will maybe get less than 1MB every few minutes. Eventually, all
the sessions get to this point with files growing ever so slowly. The only
way to "jump start" it is to cancel a session and restart the restore,
which
"usually" runs fine again for awhile until eventually slowing down to a
crawl again.

Is this enough information or should I provide more?

-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: Monday, July 07, 2003 2:37 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Restore slows to a crawl


>Has anyone else experienced a problem when restoring data where it starts
>fine but then at some random point it slows down to a crawl? The wait
time
>starts to climb to 38 seconds, then resets to 0, then climbs to 38
seconds,
>then back to 0 constantly until there is no other choice but to stop the
>session. I was running a restore as with a virtualnodename, using several
>restores at once (since im restoring almost 1TB).

Without knowing the kind of restoral you were performing or its
environment
(disk/file system configuration, collocation, tape drive type and model,
etc.)
we can only offer general suggestions.  In that you were running multiple
restore sessions at a time, certainly waiting for tape dismount and mount
will
be aggravated.  In http://people.bu.edu/rbs/ADSM.QuickFacts topic "Restoral
performance", the minimization of MOUNTRetention will help a lot.
Automatic
tape drive cleaning between tape mounts will add unaccountable time.
Directory congestion slows performance.  Data spread over tapes, with tape
technology which is poor at start-stop action is bad news.

The more information you can gather and supply, the more we can offer.

  Richard Sims, BU

Dave Canan
TSM Performance
IBM Advanced Technical Support
ddcanan AT us.ibm DOT com