ADSM-L

Re: Bad performance... again

2002-06-14 14:59:28
Subject: Re: Bad performance... again
From: Zlatko Krastev/ACIT <acit AT ATTGLOBAL DOT NET>
Date: Fri, 14 Jun 2002 20:57:47 +0300
--> The site belongs to a customer who doesn´t like very much applying 
patches.
patches.

You can apply *maintenance* not a patch by installing 4.2.2.0. You can 
point to the customer that he/she does not stay at AIX 4.3.0 but is using 
4.3.3 to get *improvements*.

--> 4. There were some noticeable performance problems on AIX (I think 
somewhere between ML08 and 09.  I think they were all fixed at 09).
somewhere between ML08 and 09.  I think they were all fixed at 09).

Actually somewhere between ML9 and ML10 :-) There was "nice" memory leak 
problem in ML9 plus some others *directly* affecting TSM performance. Thus 
you have to upgrade at least:
bos.mp
bos.rte.libc
bos.rte.libpthreads
bos.net.tcp.client
bos.net.tcp.server
ML10 seems good up to now.
Look at post made by Thomas Rupp on 10.04.2002 on thread "Big Performance 
Problem after upgrading from AIX TSM Client 4.1 to 4.2". I've learned this hard 
way but not with TSM :-)

--> To increase the cache-hit percentage you will need to shutdown TSM.
WRONG! Just use 'setopt bufpoolsize <new value>'. This also *appends* a 
WRONG! Just use 'setopt bufpoolsize <new value>'. This also *appends* a 
option line in dsmserv.opt but does not remove the old one. So you can 
clean up a bit. It is better to issue also 'reset bufpool' to clear stats 
and to get correct DB cache hit %. 
If we talk about LOGPOOLSIZE then yes, you have to change option and 
restart the TSM server.


Zlatko Krastev
IT Consultant





Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To:     ADSM-L AT VM.MARIST DOT EDU
cc: 

Subject:        Re: Bad performance... again

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.

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