I was actually replying to Brec's problem....I don't have the problem
myself. Towards the bottom of my post, I made some suggestions of my
own to him.
Don't get me wrong, I've got my own problems ;) Just not this one.
>>> ddcanan AT ATTGLOBAL DOT NET 2/3/2006 11:01:31 AM >>>
Troy, I wouldn't mind assisting here but would like you to try the
suggestion here of the other posts that have been made. Could you try
backing up a single large file to your TSM server and provide to the
listserv the output from a client instrumentation trace (using the
testflag
instrument:detail statement) and also (if possible) a server
instrumentation trace? The server instrumentation trace is started with
an
'instr begin' command before the backup begins and then ended with a
'instr
end file=some.filename.txt" command when the backup finishes.
At 01:54 PM 2/2/2006 -0600, you wrote:
>Here's some comparison data from a couple days worth of backups on
our
>two biggest groupwise servers...
>
>- Server1 is 90GB (about 24GB daily change rate), with 1,000,000
files.
>Hardware is Dual 2.4ghz Xeon's with 2.5GB RAM.
> - Last nights backup took 1h25min, and backed up 28GB.
> - Night before took 51min to backup 22GB
>
>- Server2 is 77GB (about 24GB daily change rate) with 968,000 files.
>Hardware is 3ghz Dual Xeon's with 2.5GB RAM
> - Last nights backup took 1h33min, and backed up 24GB
> - Night before took 52min, and backed up 25GB
>
>So much faster speed than yours is definitely possible. As people
>have said, there's a lot of factors to weigh, but here's some more to
>look at....
>1. Run some statistical trend graphs on the netware boxes, over the
>last week. This can be done in Remote Manager, and would tell you if
>there's disk, network, cpu, or memory bottlenecks in the server
>hardware.
>2. check the cfg files for the tsa's. (in sys:\ect\sms\tsa.cfg).
>"Enable Caching" should be set to "no", as tsm does its own. Also
check
>the "cache memory threshold. Leave it as high as possible (25 is the
>max), and reduce in increments of 5 percent if it gives you trouble.
>3. Update all the firmare & drivers for disk controllers and nic's.
>4. Have someone check the statistics on the switch ports of these
>servers. If you're seeing lots of crc errors,retransmits, or other
bad
>signs, then there's probably a speed/duplex problem between the nic &
>switch. There is no one rule that always works, so try all
>possibilities (if you're hardcoding, try setting auto, and
vise-versa).
>
>
> >>> bwhitten AT UABMC DOT EDU 2/2/2006 12:38:41 PM >>>
>Hi all,
>
>Netware group at our location is not happy with backup
>and restore performance using TSM. We are seeing roughly
>4 to 5 GB per hour at best. We have tested going to SSA disk
>pools, SATA disk pools and directly to 3590/3592 tape FC. We
>don't see very much difference in these methods. Typical Netware
>client is 150,00+ files with 25 to 40 GB per client. We also have
>Groupwise and the performance for those is roughly 20 percent
>worse.
>
>Clients are mostly 5.1 and 5.2.
>
>TSM servers are P615/4GB ram and P520/4GB ram running AIX 5.2
>and TSM server 5.2.3
>
>Most clients are GB Eth and we see similar performance on Windows
>servers with similar volume sizes/number of files. It seems to me
that
>this is mostly a function of a large number of small files. We also
>have
>AIX, Solaris and Oracle clients and performance is generally better
>on those clients (especially Oracle Rman/TDP).
>
>I have looked through the postings and have not been able to glean
>much of a consensus about what throughput should be for this type
>of configuration. We have tried many of the parameter changes that
>have been suggested ( buffer/tcp window sizes, quiet option, etc.)
>without much success. If anyone has overcome these types of problems
>or can give me some definitive answers ( even if the answer is
'that's
>the
>best you'll get' ), please e-mail me offline.
>
>Thanks for reading and thanks to all who post on this site.
>
>
>Brec Whitten
>
>UAB Hospital
>
>
>Confidentiality Notice follows:
>
>The information in this message (and the documents attached to it, if
any)
>is confidential and may be legally privileged. It is intended solely
for
>the addressee. Access to this message by anyone else is unauthorized.
If
>you are not the intended recipient, any disclosure, copying,
distribution
>or any action taken, or omitted to be taken in reliance on it is
>prohibited and may be unlawful. If you have received this message in
>error, please delete all electronic copies of this message (and the
>documents attached to it, if any), destroy any hard copies you may
have
>created and notify me immediately by replying to this email. Thank
you.
Dave Canan
TSM Performance
IBM Advanced Technical Support
ddcanan AT us.ibm DOT com
Confidentiality Notice follows:
The information in this message (and the documents attached to it, if any)
is confidential and may be legally privileged. It is intended solely for
the addressee. Access to this message by anyone else is unauthorized. If
you are not the intended recipient, any disclosure, copying, distribution
or any action taken, or omitted to be taken in reliance on it is
prohibited and may be unlawful. If you have received this message in
error, please delete all electronic copies of this message (and the
documents attached to it, if any), destroy any hard copies you may have
created and notify me immediately by replying to this email. Thank you.
|
