Thanks for your email.
We moved our test bed to a bigger ProLiant server and had 2.3MBps on
restores (2 threads). Then we uncompressed the data, backed it up,
and restored it. We then saw a single threaded restore (1 RAID-5
partition) restore at 3.1MBps which = 11.6GBph. That is acceptable
performance for my customer. They are putting a plan in place to
buy more disk space and move to an uncompressed partition. This
will be the best solution for them.
--
Joshua S. Bassi
IBM Certified- AIX Support, HACMP, SAN
Enterprise Disk(Shark)& Tape Solutions
Tivoli Certified Consultant - ADSM/TSM
[EMAIL PROTECTED]
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
France, Don G (Pace)
Sent: Friday, November 17, 2000 12:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Windows NT Restore Performance
Josh,
You might consider using a Perl script to generate a load-balanced list of
directories then run INCR for multiple items in that list (say 10 at a
time). This may work, for you as it will use the "selective incremental"
feature (which doesn't update the last-incr-date for the file system), then
once a week (or more) run a normal full-incremental to update the server's
setting for last-incr-date. (Did you see only one thread on restore, also?
The design doc. says the new multi-thread only works for backup/archive
direction. Also, this multi-thread/session feature *may* depend on multiple
file systems or file-spec's to get it to run multiple data-flow threads...
also, there are implications for number of available mount points; the
default number of session-threads of two uses one thread for "query info"
and one or more for backup data.)
I saw the problem with compression back in the SJ lab; unfortunately, the
NTFS attributes go with each file, and for TSM client to "copy" a file to
backup/archive storage, the NTFS API decompresses the file on backup, then
recompresses it on restore. This, combined with progressively degrading
NTFS performance (over huge numbers of files/directories) made the client
CPU the main bottleneck. You may need 4 CPU's to get decent performance out
of more than one session for restore! (BTW, is your server still NTFS4? I
wonder if NTFS5 helps this issue, any. We are about to start testing on
Win2k restores, so I will post what we learn.)
Don France
Technical Architect - Unix Engineering/P.A.C.E.
San Jose, CA
mailto:[EMAIL PROTECTED]
PACE - http://www.pacepros.com
Bus-Ph: (408) 257-3037
-----Original Message-----
From: Joshua S. Bassi [mailto:[EMAIL PROTECTED]]
Sent: Thursday, November 16, 2000 11:57 AM
To: [EMAIL PROTECTED]
Subject: Re: Windows NT Restore Performance
Unfortunately my customer has created one huge data partition with only
one main directory on it. There are 2000 small directories under that
directory. So there is really no way to run multiple streams against
that. And to top it off it is not only a compressed NTFS volume, but
a 3-4 disk RAID-5 set, so when I use the GUI for the restore, it only
fires off 2 streams (1 for send & 1 for receive).
Thank you,
Josh
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Kelly J. Lipp
Sent: Thursday, November 16, 2000 11:50 AM
To: [EMAIL PROTECTED]
Subject: Re: Windows NT Restore Performance
About 10 GB/Hour is what I see with a single stream. Get a couple of
streams working on the problem and you can saturate the network. I assume a
100 MBit network.
Kelly J. Lipp
Storage Solutions Specialists, Inc.
PO Box 51313
Colorado Springs CO 80949-1313
(719) 531-5926
Fax: (719) 260-5991
Email: [EMAIL PROTECTED]
www.storsol.com
www.storserver.com
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of
Joshua S. Bassi
Sent: Thursday, November 16, 2000 12:33 PM
To: [EMAIL PROTECTED]
Subject: Windows NT Restore Performance
All,
What type of performance are you getting backing up Windows NT
servers to an RS6K ADSM server? I have a customer who was
getting 650KBps on a restore from a disk storage pool. After
I made some performance tuning changes (i.e. TCPWindowsize 32,
TCPBuffsize 32, upgrade the client to 4.1.1.16, Resource 10,
largecom yes, txnbytelimit 25600 etc.) our performance is up
to 1.29MBps. That still seemed slow. Then I found that my
customer is using NTFS compression for the entire data
partition. When we turned compressed off and also uncompressed
the data before backup, our transfer rates got up to 3.1MBps
- that's 11GBph.
1) What type of rates are everybody seeing on NT file system
restores?
2) If we backup the data with the compressed attribute, and
then uncompress the entire volume including the data, then
restore the data from ADSM, the data comes back compressed
on the file system bringing my rate down to the 1.29MBps.
I would like it to come backup from ADSM on the NTFS file
system uncompressed so that the restore will be at the
3.1MBps rate, but I haven't found a way to do that. Is there?
AIX 4.2.1 ADSM 3.1.1.5 (upgrade plan in progress)
Windows NT SP5 TSM 4.1.1.16
Average file size 65KB
100 Ethernet fast-duplex hard-coded
We are not retrying to backup files and we are not using
client compression.
--
Joshua S. Bassi
IBM Certified- AIX Support, HACMP, SAN
Enterprise Disk(Shark)& Tape Solutions
Tivoli Certified Consultant - ADSM/TSM
Cell (408) 332-4006
[EMAIL PROTECTED]
