> Any other ideas? To isolate a possible networking issue, in the past, I have ftped some files between the TSM server<--->Client just to verify network is cool.
Sung Y. Lee "ADSM: Dist Stor Manager" <[email protected]> wrote on 12/22/2005 08:09:23 AM: > Thanks for the responses all, but it's not a tape mounting issue. I wasn't > clear enough in my original post, but I am watching the actlog while the > restore is taking place, and I'm sitting next to the library, so I can > tell when it's doing anything: remounting, rewinding, etc. What I'm > saying is this: > > The server is restoring a single 32GB file, and starts doing so at > 30+MB/sec. At some point, DURING the restore of that SAME 32GB file, the > server suddenly slows down the restore, to 200-300K/sec. The server has > NOT switched tapes, and is NOT rewinding even the SAME tape. It is still > restoring that same 32GB file, but suddenly does so at a slower speed. > > I know the drives have some kind of burst speed and normal speed. Maybe > something is wacked out with that function? > > Any other ideas? > > Alex > > On Thu, 22 Dec 2005, Leigh Reed wrote: > > > Alex > > > > I hate restores that don't go as fast as I want them to, especially when > > it's 3 o'clock in the morning, so I'll have a stab at what might be > > wrong. The nature of your problem does seem very intermittent and the > > fact that some times you do achieve an acceptable speed makes it > > difficult. > > > > Firstly, I think you need to know what primary pool tapes your data is > > across. As Troy mentioned, if you are not collocating (or collocating by > > group), then the data is going to be spread across a large number of > > tapes. Even if you are collocating (all data on one tape), remember that > > you are restoring the active data only, the tape will contain all the > > previous and deleted versions (depending upon your backup copy group > > parameters). During the restore, the tape will have to skip between > > these; while this is happening, your aggregate network performance will > > decrease, as nothing is being restored. > > > > The following command will list the primary volumes that the node data > > is across > > > > select volume_name from volumeusage where node_name='xxxxxxx' and > > copy_type='backup' and stgpool_name='PRIMARY_TAPE_POOL' group by > > volume_name > > > > If this returns a large number of tapes, then you have 2 options > > available to you. Use a 'multi-thread' restore, by increasing the > > resourceutilization setting in the client dsm.opt file and also > > increasing the MAXNUMMP parameter. This will enable you to restore > > multiple tapes concurrently (depending on the number of drives that you > > have available). Please note that multi-threading only works with No > > Query Restores. > > > > The second option is as Troy alluded to with a MOVE NODEDATA, but if > > memory servers me right, the elusive 'Active only' switch is still not > > available, therefore the tape restore will still have to skip through > > the data that is not active. > > > > If all of the above is completely evident to you, then we are back to > > the old favourite; try FTP'ing a large directory of files from the TSM > > server to the target restore server, this should test out your network > > and filesystem performance. > > > > The only other suggestion would be to take a look at what your TSM > > server is doing at the time of the restore. > > - are you doing the restore at night when a large number of backups are > > occurring > > - is expiration running at the time of the restore > > - during the restore, keep issuing 'q sess' commands and see if the > > restore is 'clocking up' recw, sendw, commw time. > > > > One other thing I have just remembered, if you are doing a full BMR and > > you have restored the OS first and rebooted, your restored OS may have > > virus scanning enabled and if it is set to scan on write, when you > > restore the remaining drive(s), every file will be scanned before it is > > written, this will definitely slow down your restore. Task manager > > should show the virus scanner chewing up CPU. > > > > HTH > > Merry Xmas One and All. > > Leigh > > > > > > -----Original Message----- > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of > > Alexander Lazarevich > > Sent: 21 December 2005 19:47 > > To: [email protected] > > Subject: [ADSM-L] restore speed question > > > > TSM server 5.3.1 on 2K server. Libraries are one Overland Neo 4100 with > > 2 > > LTO2 drives, and an Overland Neo 4100 with 2 LTO3 drives. > > > > I'm restoring a windows client workspace. Client is running TSM backup > > client version 5.3.0. Originally, the client was 5.1.9.0, and it was > > with > > this version that we first created the backup of the workspace drive on > > the client. > > > > Now I'm trying to restore that workspace filespace to the new system. > > The > > restore started fine, 30MB+/sec in our GigE network. But at times the > > restore speed slows to a halt, and restore speeds are less than 1MB/sec, > > sometimes only 200-300K/sec. Then a little later it will start to go > > 30MB/sec again. It is switching back and forth, sometimes in the middle > > of > > a file! The server is currently trying to restore an 86MB file, but it's > > doing so only at 300K/sec. Being that the workspace is 244GB, this is > > unacceptable speed. > > > > The client data is on the LTO2 library. There is absolutely nothing > > unusal in the logs that would indicate any kind of problem on the drive > > or > > the tape. No errors are being reported whatsoever. > > > > The client filespace is NOT compressed on the client side. Compression > > happens on the drives (HP). > > > > The client hardware is excellent, dual AMD opteron, with 3G SATA drives > > in > > striped RAID, XP Pro. Plus the client at times restores at 30+MB/sec so > > I > > know it can do it. > > > > Network on the client is not busy, and the network switch is not > > saturated, in fact there is very little network activity. > > > > It just seems like the server decides to go fast at times and then > > sometimes very slow. But with nothing in the logs I don't know what to > > troubleshoot. Any idea where to start troubleshooting this problem? > > Anyone > > seen this type of behavior before? > > > > Thanks! > > > > Alex > >
