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" <[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
Dave Canan TSM Performance IBM Advanced Technical Support [EMAIL PROTECTED]
