ADSM-L

Re: [ADSM-L] Help! Trying to figure out what caused slow performance

2007-08-08 08:49:05
Subject: Re: [ADSM-L] Help! Trying to figure out what caused slow performance
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 8 Aug 2007 06:50:22 -0600
Try the SUMMARY table on the TSM server, e.g.:

select * from summary \
   where start_time>='2007-08-07 05:00:00' and \
      end_time<='2007-08-07 05:37:00' and \
      activity='ARCHIVE' and \
      entity='FJSU102'

How certain are you that for that archive operation there was no tape
mount activity? Be sure to review the ENTIRE, UNFILTERED activity log just
to make sure there was no tape mount activity.

Lastly... is the problem repeatable? Do you experience it for backup as
well? Create a test file ~500 MB in size, and do a selective backup...
does it take a long time to back up? While the operation runs, issue QUERY
SESSION from an admin CLI, and watch the session state and bytes received.

If selective backup runs fine, repeat for archive. Any difference?

Can you replicate this problem on a different, but similarly configured
client system?

If the problem does not occur on other client systems, then you probably
are shooting some kind of network problem on the client machine itself.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Product Development
Level 3 Team Lead
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com

IBM Tivoli Storage Manager support web page:
http://www.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.

"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 08/08/2007
04:58:43 AM:

> Hi Richard,
>
> By the time I was notified of the issue the TSM client in question,
> fjsu102, had already sent additional data.  Where might I be able to get
> the accounting logs on the client?  This process from the client was
> actually an archive that was going directly to disk on the TSM server
and
> it was only about 461 KB.  No migrations were running from that
particular
> disk pool and there were no admin tasks copying the data to a copy pool.
I
> also didn't see any errors in the TSM activity log during this time
> period.
>
> Thanks for the advise!  I'll take a look again at the performance guide
to
> see if I have missed anything.
>
> ********************************
> Joni Moyer
> Highmark
> Storage Systems, Storage Mngt Analyst III
> Phone Number: (717)302-9966
> Fax: (717) 302-9826
> joni.moyer AT highmark DOT com
> ********************************
>
>
>
> "Richard Sims" <rbs AT BU DOT EDU>
> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> 08/07/2007 02:40 PM
> Please respond to
> "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>
>
> To
> ADSM-L AT VM.MARIST DOT EDU
> cc
>
> Subject
> Re: Help! Trying to figure out what caused slow performance
>
>
>
>
>
>
> On Aug 7, 2007, at 9:38 AM, Joni Moyer wrote:
>
> > Any suggestions/help in determining what the cause of this might be
> > would
> > be greatly appreciated!!!!!
>
> The usual starting places...
> Performing Query SEssion during the activity gives you a real-time look;
> and performing 'netstat' on AIX allows you to gauge delay source.
> Performing Query Node ... Format=Detailed right after the backup will
> yield
> wait time values which help show where delays were occurring.  Or you
> can
> look at the accounting records.
>
> You don't indicate the nature of the backup.  Whereas there were ANE
> records
> in the TSM server Activity Log, this should not have been an API-
> based TDP
> type of backup, thus suggesting that either Oracle was shut down or
> that the
> backup was "wild", and so standard issues affecting throughput
> (client factors,
> including file region locking; TSM storage pool speed, etc.).  See
> the TSM
> Performance Tuning Guide for many things to review.  ADSM QuickFacts
> summarizes
> numerous elements which can affect backup performance.
>
>     Richard Sims