ADSM-L

Re: [ADSM-L] SQL queries and TSM Server/platform performance measurement

2007-07-25 18:08:59
Subject: Re: [ADSM-L] SQL queries and TSM Server/platform performance measurement
From: Dave Canan <ddcanan AT ATTGLOBAL DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 25 Jul 2007 14:39:55 -0700
        I'd like to comment on these queries, being as I was the one who
originally submitted that technote to the IBM database. First, the queries
are a little old, and they were recently revised to higher values to
reflect newer disk subsystems. On the Full DB Backup query, we now look for
an overall rate of ~ 28GB/hr hour as an acceptable rate.

        But there is another important correction to these queries. When
these were originally created several years ago, we stated that if these
benchmarks were not being met, then you definitely had a disk performance
issue. We then ran into several customers who despite not meeting these
benchmarks, had perfectly acceptable performance on their disk
subsystems.  So now we use these SQL queries as a first step in seeing
whether or not there "might" be a performance issue. If we don't get
acceptable numbers using these queries, we then usually dig deeper with
server instrumentation traces and perhaps other TSM traces as well. These
should only be used as a first step benchmark to see if deeper analysis
might be needed.


At 04:47 PM 7/25/2007 +0100, you wrote:
Hi Guys,

Every now and then I come across a SQL query and a benchmark such as the
following which purports to be useful in high-level performance problem
spotting. For example:

select activity, cast((end_time) as date) as "Date", (examined/cast
((end_time-start_time) seconds as decimal(18,13))*3600) "Pages backed
up/Hr" from summary where activity='FULL_DBBACKUP' and days(end_time) -
days(start_time)=0

or

select activity, cast((end_time) as date) as "Date", (examined/cast
((end_time-start_time) seconds as decimal(24,2))*3600) "Objects Examined
Up/Hr" from summary where activity='EXPIRATION'

alongside statements that values of less than 5,000,000 pages per hour
and 3,800,000 pages per hour respectively might indicate a performance
issue somewhere in the stack. Has anyone else seen these, or similar
ones, as well?

My concern is that the article I've just come across which contains the
above, quoted from an IBM White Paper, might be a little on the old
side, and particularly with the later expiration query, I'm getting
figures for one system which suggest it should be crawling on its knees
when instead I'd tend to think it's a pretty damn good performer. As I'm
sure TSM Server code improves the expiration algorithm with each
revision, then it's more likely that this later query, and as
importantly the benchmark which goes with it, might get obsoleted.

Does any one have any thoughts on these? Does anyone else have any other
queries or benchmarks which they run from time to time for
'tip-of-the-iceberg' performance troubleshooting.

Rgds,

David McClelland
London, UK









This email was sent to you by Reuters, the global news and information
company.
To find out more about Reuters visit www.about.reuters.com

Any views expressed in this message are those of the individual sender,
except where the sender specifically states them to be the views of
Reuters Limited.

Reuters Limited is part of the Reuters Group of companies, of which
Reuters Group PLC is the ultimate parent company.
Reuters Group PLC - Registered office address: The Reuters Building, South
Colonnade, Canary Wharf, London E14 5EP, United Kingdom
Registered No: 3296375
Registered in England and Wales

Dave Canan
TSM Performance
IBM Advanced Technical Support
ddcanan AT us.ibm DOT com

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