ADSM-L

Re: Bad performance... again

2002-06-16 23:10:03
Subject: Re: Bad performance... again
From: Michael Benjamin <MBenjamin AT BUNNINGS.COM DOT AU>
Date: Mon, 17 Jun 2002 10:29:39 +0800
Hello Zlatko,

Thanks for the "setopt bufpoolsize". The manual didn't seem to mention this,
it seemed the only
way to do it was via editing dsmserv.opt directly. Yep resetbufpool is also
necessary for 
monitoring the cache performance by getting rid of the old stats and is
mentioned in the manual
as part of the steps to perform.

When you say clean up dsmserv.opt, does that mean there are two uncommented
lines and one
overrides the other? If so this seems like an odd way of doing things...


> -----Original Message-----
> From: Zlatko Krastev/ACIT [SMTP:acit AT ATTGLOBAL DOT NET]
> Sent: Saturday, June 15, 2002 1:58 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: Bad performance... again
> 
> --> The site belongs to a customer who doesn´t like very much applying 
> 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).
> 
> 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 
> 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.
> 
> **************************************************************************

**************************************************************************
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>