Correction... the traceflag is instr_client_detail, then use tracemax=4000
(for wrap-around) and tracefile=xxx.out.
Don France
Technical Architect - Unix Engineering/P.A.C.E.
San Jose, CA
mailto:dfrance AT pacbell DOT net
PACE - http://www.pacepros.com
Bus-Ph: (408) 257-3037
-----Original Message-----
From: France, Don G (Pace)
Sent: Friday, May 04, 2001 9:50 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: RE: Slow restore for large NT client outcome.. appeal to
Tivoli
I have two fundamental suggestions, I have not seen item 2 mentioned yet:
1. Use Microsoft folder-copy (be sure to run WinDiff - it's notorious for
*not* copying all the files/directories) - and compare performance for
copying large number of customer files;
2. Run the instrum_client_detail trace - this is a client-level trace
option, very cool, documented in a number of old ATSC and Performance info
papers from the old ADSM days... it still works, and provides a very clear
view of where time is being spent during backup/restore.
We are exactly in that position with a very large client; we just ordered
6-drive, 72-slot LTO and H80 to handle existing 1.6 TB of file served data
occupancy across 5 NT servers, some 7 million files/dirs. We will also
mitigate the failure-recovery scenario to a large extent with fibre-attached
EMC storage, replacing old dual P-Pro with latest Compaq server gear. As
part of our "little" fix-it project, we will be doing some benchmark
measurements; I, for one, plan to use both of the above listed methods to
confirm/reset our expectations... sure hope we can do better than 5-10 GB/Hr
restore speed. (Maybe will try Win2K as well as NT - if there is a
possibility of keeping the resulting member server.)
BTW, we did get some numbers from Tivoli/IBM indicating NT is the slowest,
but all 3 platforms (NT, Solaris, AIX) are slowest with large numbers of
small files (AIX is, by far, the fastest in their benchmarks!). We
considered switching to Samba-like solution (with AIX), just so we could use
the IMAGE backup for fast restore; that is how ArcServe can beat TSM -
also, that's (somewhat) how Replica beats TSM, and that's one advantage of
TDP for Workgroups... too bad the owning children could not get along
well-enough to move that solution forward (ie, sending TDPfW data across LAN
to TSM server).
At this point, we're betting on (a) EMC reliability & recoverability
(RAID-S), (b) combination of EMC and newer Compaq gear for better
performance, and (c) TSM-5.1 (1q02) delivery of image backup for Win2K!
Regards,
Don
-----Original Message-----
From: Kelly J. Lipp [mailto:lipp AT storsol DOT com]
Sent: Wednesday, September 20, 2000 2:38 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Slow restore for large NT client outcome.. appeal to
Tivoli
Could someone with experience doing large restores with ArcServe or
BackupExec provide some performance numbers? I've been in shops where the
backups were taking a very long time. Longer than my TSM backup took. I
never witnessed a restore but how can it be better.
I want the facts. I'm tired of hearing about how much faster ArcServe and
BackupExec are (in theory) compared to TSM in reality.
I'm sick and tired of it and I won't take it anymore!
This is what happens when you TSM 24 hours per day. Your brain. Your brain
on TSM. Not a pretty picture.
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (719) 260-5991
Email: lipp AT storsol DOT com
www.storsol.com
www.storserver.com
|
