Thanks for that David,

To increase the cache-hit percentage you will need to shutdown TSM.

Backup and edit BUFPOOLSIZE in dsmserv.opt and restart the TSM server.
It's probably worth going through an unloaddb and reload of the database
also to
improve performance. We're looking at doing this as a quarterly procedure.

BUFPOOLSIZE refers to virtual memory, default is probably 4096. There is a
table
in the Admin Guide which recommends increases in BUFPOOLSIZE according to
system memory. I'd recommend being a bit conservative and grow it a bit at a
time
performing a "q options" and "q db f=d" to see what's going on with
BUFPOOLSIZE in
relation to cache-hits. You obviously don't want to use up virtual-memory at
peak load
times.

Mike.

> -----Original Message-----
> From: David Longo [SMTP:David.Longo AT HEALTH-FIRST DOT ORG]
> Sent: Friday, June 14, 2002 9:15 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Bad performance... again
>
> Well, I'll take a few shots.
>
> 1.  Network - Have you tried some FTP or similar tests at OS level
> between TSM server and clients to see if Network performance is o.k.?
>
> 2.  Your Atape driver is WAY behind.
>
> 3.  Drive microcode on 3584 is behind (Not as far as Atape though).
>
> 4. There were some noticeable performance problems on AIX (I think
> somewhere between ML08 and 09.  I think they were all fixed at 09).
>
> 5.  On TSM server, what is the "cache hit percent" output of
> "q db f=d"?  If it is much less that 98%, the cache needs to be
> increased.  This can effect a lot of TSM server ops.
>
> 5.  You didn't mention how long this server has been in operation
>  - was it working fine at one point and went downhill?  Also what
> Disk you have on TSM server and how setup?
>
> David Longo
>
> >>> paul AT VANGUARD-IT.COM DOT BR 06/12/02 10:50AM >>>
> Hi everybody,
>
>
>    I know this is a subject that comes very often, and that various
> answers
> were already give, but, after searching through the list archives, I am
> still not totally sure of what I should do:
>
>    I have a TSM Server that does his backups not quite fast. First, I
> thought of a network problem, but it is a dedicated backup network running
> at 1Gb/s and I only get backups at 10GB/hour. And, the internal server
> operations (reclamation, backup stgpool) are also slow. Right now, I am
> looking at the console a backup stg process which is running for almost 2
> hours and has backed up only 38GB. It is a new pool, so there is no time
> spent searching the new files, and all the data came from one volume.
>
> My setup is:
>
> TSM Server 4.2.0.0  (Client wants to upgrade to 5.1)
> AIX 4.3.3 ML9 on an F80 with 2 CPUs
> ATAPE 5.4.2.0
>
> Storage is:
>
> IBM3584 with 6 IBM LTO drives. Microcode level is 16E0
>
> The site belongs to a customer who doesn t like very much applying
> patches.
> Should I try to convince him to upgrade TSM/ATAPE/Microcode? Or is there
> anther issue?
>
>
>
> Thank you in advance for your attencion
>
> Paul van Dongen
>
>
>
> "MMS <health-first.org>" made the following
>  annotations on 06/13/02 21:31:29
> --------------------------------------------------------------------------
> ----
> This message is for the named person's use only.  It may contain
> confidential, proprietary, or legally privileged information.  No
> confidentiality or privilege is waived or lost by any mistransmission.  If
> you receive this message in error, please immediately delete it and all
> copies of it from your system, destroy any hard copies of it, and notify
> the sender.  You must not, directly or indirectly, use, disclose,
> distribute, print, or copy any part of this message if you are not the
> intended recipient.  Health First reserves the right to monitor all e-mail
> communications through its networks.  Any views or opinions expressed in
> this message are solely those of the individual sender, except (1) where
> the message states such views or opinions are on behalf of a particular
> entity;  and (2) the sender is authorized by the entity to give such views
> or opinions.
>
> ==========================================================================
> ====

**************************************************************************
Bunnings Legal Disclaimer:

1)      This document is confidential and may contain legally privileged
        information. If you are not the intended recipient, you must not        
                                                disclose or use the information 
contained in it. If you have
        received this e-mail in error, please notify us immediately by
        return email and delete the document.

2)      All e-mails sent to and sent from Bunnings Building Supplies are
        scanned for content. Any material deemed to contain inappropriate
        subject matter will be reported to the e-mail administrator of
        all parties concerned.

**************************************************************************