John,
I am experiencing similar problems here. My backup performance is
fantastic, but my restore performance is poor. All my variables (server,
client, code levels, LTO, etc...) are similar to yours, except we're on
Gigabit Ethernet. I've even tried eliminating the LTO's from the picture by
restoring from cached disk pools. I recommend you try that yourself and see
if your performance changes. Even though I tried that here, it didn't seem
to help much - so I don't think the LTO technology is the problem.
Even with using the disk pools for the source, I still see the long delays
like you see. I've found some things that seem to slightly improve
performance IN A TEST ENVIRONMENT. These things are:
- performing multiple restores at the same time
- restoring from a command line rather than the GUI
- restoring entire volumes rather than individual files.
Obviously, you can't rely on those methods in the real world. Tivoli
support hasn't given me a very good answer yet either... They suggest that
TSM is looking through the database to decide what files to restore next.
Yeah, right...
This is (so far) my only real complaint about TSM. But the whole reason we
do backups anyway is so we can restore, right...? Please let me know what
you find out and I'll do the same for you.
Thank you,
Jeff Caffey
Enterprise Systems Programmer
(AIX & Storage Administrator)
Pier 1 imports, Inc. - Information Services
jlcaffey AT pier1 DOT com
Voice: (817) 252-6222
Fax: (817) 252-7299
-----Original Message-----
From: John Schneider [mailto:jdschn AT ATTGLOBAL DOT NET]
Sent: Thursday, May 03, 2001 8:40 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: LTO restore performance - seek problem?
Greetings,
I have seen many posts on adsm.org about LTO, but none that
addresses the problem I am seeing. Backup speed seems to be fine, at
least as far as I can tell. But when I do a restore, I see a strange
behavior. The restore seems to happen in bursts, where the restore
pulls back files lickety-split for a awhile, then stops for 15-20
minutes, then continues. I think that the wait is the seek from one
spot on the tape to another. We have two tape drives in the IBM 3583
library, and the problem seems to be happening on both of them. We
upgraded to the 0CE1 version of the LTO microcode, but it has not
improved things that I can tell.
We restored 1.5 GB from our RS/6000 TSM server to a NT client, and
it took 47762 seconds, or 13 hours. All the data was on one tape, so it
is not a colocation problem. How long should it take an LTO drive to
seek? I have done these sort of restores on DLT, and it can usually get
from any place to any place on a tape within a few minutes. I expected
LTO to be at least as good. A 13 hour restore is completely
unacceptable.
Any input or things to try would be appreciated. By the way, the
TSM server is an RS/6000 F50 running AIX 4.3.3 ML4, with TSM 4.1.2. It
is running atape 6.0.4, and atldd 4.1.5.0, which are both the latest, I
believe. The NT client was TSM 4.1.2. Both are on the same switch on a
100MB Ethernet network, so I don't think the network is related in any
way.
TIA,
John Schneider
***********************************************************************
* John D. Schneider Email: jdschn AT attglobal DOT net * Phone: 636-492-0247
* Lowery Systems, Inc.
* 1329 Horan Disclaimer: Opinions expressed here are
* Fenton, MO 63026 mine and mine alone.
***********************************************************************
|
