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" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
07.07.2003 22:08
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
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:[EMAIL PROTECTED]
Sent: Monday, July 07, 2003 2:37 PM
To: [EMAIL PROTECTED]
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
