ADSM-L

Re: tsm

2006-02-23 00:50:03
Subject: Re: tsm
From: Roger Deschner <rogerd AT UIC DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 22 Feb 2006 23:49:36 -0600
I have seen a 1 gigabit NIC run at speeds as fast as 450 megabits, for a
sustained period of time, on an AIX TSM server. 450 megaBITs/sec is 162
gigaBYTEs/hour. In our 14-hour backup window, we typically back up 1TB
of data.

So your NIC is probably not the problem. Look first at your network -
all the way to the client node. "Gigabit infrastructure" can still have
bottlenecks, and TSM backups can stress a network like no other
application.

However, I have also seen that speed limited by disk contention in both
the TSM Database, and in the first (disk) storage pool. Look at your
Database cache hit ratio (Q DB F=D), and raise your database cache
(using SETOPT BUFPOOLSIZE) until your hit ratio is consistently over
98%. Each time you raise the buffer pool, reset the cache hit statistics
counter with RESET BUFPOOL, and then let it run for at least an hour.
Check out the option in the Server Options File that will automatically
adjust your BUFPOOLSIZE for you.

If you are backing up directly to tape, you are probably "shoeshining"
the tape drive, which is very, very slow. (It also wears out your tape
drive heads, and your tape media, very quickly.) You need a disk storage
pool in between the network and the tape drive, so the tape drive can
work in its much faster streaming mode.

Roger Deschner      University of Illinois at Chicago     rogerd AT uic DOT edu
==="If a train station is where a train stops, what's a work station?"==


On Wed, 22 Feb 2006, Troy Frank wrote:

>I can't speak to all brands/models since I haven't seen them all.
>However, all the brands/models of 1GB NIC that I have seen only work if
>set to auto.  I've never seen an instance where forcing 1gb/full duplex
>was even an option.  Of course, this also means that the switchport has
>to be set to auto.  If you try to force it, that will somtimes prevent
>it from linking correctly at 1gb.
>
>That said, I agree that the issue sounds like a network or client
>config issue.  Even if another transfer type (like ftp) can't be tried
>between the same peers, is it possible to do a ftp transfer from the
>trouble machine to a different server (i.e. not the tsm server)?  We
>just need to know if it gets slow transfer ONLY between itself and tsm,
>or if it happens from that machine to any other machine.
>
>>>> gmichala AT US.IBM DOT COM 2/22/2006 3:22:40 PM >>>
>Chances are it's not a TSM issue at this point but a network issue.
>
>Usually speeds this slow on a GB infrastructure indicate that
>"auto-negotiation" is not working. ( never does ).
>
>Make sure all NIC's and switch ports are locked down to 1GB at full
>duplex.
>
>Gerald Michalak
>TSM - Certified V5 Administrator
>
>
>
>
>"ADSM: Dist Stor Manager" < ADSM-L AT VM.MARIST DOT EDU > wrote on 02/22/2006
>01:15:04 PM:
>
>> Hello,
>>
>> First of all, I know almost nothing about Tivoli so bear with me :)
>> Now, do you have any idea what's the maximum throughput between a
>TSM
>client
>> and server, during a backup? Let's assume that we have a GB
>infrastructure
>> connecting them. I'm experiencing really low speeds (3-4MBps) and
>> unfortunately it's impossible to try some other kind of data
>transfer
>(via
>> ftp for ex.) between the same peers.
>>
>> Thanks!
>>
>> Octavian
>
>
>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.
>

<Prev in Thread] Current Thread [Next in Thread>