ADSM-L

AW: Incredibly slow restore

2001-01-29 10:11:50
Subject: AW: Incredibly slow restore
From: Stefan Holzwarth <stefan.holzwarth AT ZENTRALE.ADAC DOT DE>
Date: Mon, 29 Jan 2001 16:03:13 +0100
ADSM. Mailing List dec 2000 :AW: Slow restore for large NT client

> What I think is happening is this:
> Due to the incremental forever backup method the files are becoming
> fragmented on the tapes. A file changes so a new version is 
> written to the
> tape. The oldest version is then deleted  leaving a gap on 
> the tape. The
> problem with fragmented tapes is that the seek speed of the 
> tape drives is
> very slow.

This is also my opinion and you should have a look at the managementclasses:

If you have 3 additional versions of a file and all of the data fits onto a
single tape
you have only 25% (1+3/100) information on that tape - means only 25%
throughput...

With Regards 

Stefan Holzwarth


> -----Ursprüngliche Nachricht-----
> Von: Geirr Halvorsen [mailto:geirr.halvorsen AT FOURLEAF DOT DK]
> Gesendet am: Montag, 29. Januar 2001 14:31
> An: ADSM-L AT VM.MARIST DOT EDU
> Betreff: Incredibly slow restore
> 
> Hello people,
> one of my customers is running into the following problem;
> With TSM server 3.7 on NT 4 sp6a, and TSM client 3.7 on NT4 
> sp6a, restore
> is really slow. Checking all normal parameters in both server 
> and client
> .opt files does not seem to help. My suspiscion is then 
> turned to network
> issues, but according to the customer, they do not have any network
> problems.
> 
> When I restore using the client GUI, and watch the status 
> indicator, when a
> file reaches 100%, it waits for a long time (bigger file - 
> longer time)
> before it continues with the next, I have also watched
> performance/utililzation of CPU, memory and network traffic, 
> on both client
> and server while doing this, and none of these indicates that 
> something is
> unusual. Both CPU and mem is low, network is maxed, but drops 
> when a file
> is done. The result is a throughput somewhere around 950MB 
> per hour. Not
> very impressing.
> 
> Is this likely to be a TSM problem, or in other words - where 
> should I go
> from here?
> 
> Any suggestions will be helpful!
> 
> 
> Geirr Halvorsen
> Tech, Consultant
> FourLeaf Technologies
> Denmark.
> 
<Prev in Thread] Current Thread [Next in Thread>
  • AW: Incredibly slow restore, Stefan Holzwarth <=