ADSM-L

Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned

2007-07-27 13:47:57
Subject: Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned
From: Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 27 Jul 2007 13:39:51 -0400
Assuming the SATA are on AIX, were the logical volumes set up to hold
the volumes
defined as JFS2?

>>> ian-it.smith AT DB DOT COM 07/27/2007 2:30:54 PM >>>
Do the client backup sessions pin the log? What is the throughput on
the
actual client session and are these backups direct to disk? If the
sessions are cancelled does the system come back to life?

15 TB of SATA sounds like a lot of storage. how has this been
added/configured- What raw throughput do you get on these disks outside
of
TSM itself?

You say the LTO3 drives are new. Do you have existing LTO3 drives?
Have
you configured them correctly with new device class etc if you are
mixing
LTO generations in the library?

I have seen this type of pinning/dramatic slow down before. I saw
itself
manifest by the server hitting the maxsessions limit as all the
sessions
were running so slowly to the disk pool.

Lots of questions i know, but as you have made multiple changes at the
same time- its going to be difficult to nail down without additional
info.

Ian Smith
-------------------------------------------------------
Core Engineering - Storage





Robert Clark <Robert_Clark AT MAC DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
27/07/2007 18:01
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: [ADSM-L] TSM performance very poor, Recovery log is being pinned






Is the SATA setup as disk storage pools? Is it filesystem or raw
logical volumes?

What is the OS? vmstat or top/topas may give some ideas.

What is the network transport? Fast ethernet?

[RC]

On Jul 27, 2007, at 2:49 AM, Craig Ross wrote:

> 10 days ago I Recently added 15TB of SATA storage and a new Fabric
> with 4
> new LTO drives to our 3584 library,
> The DB is approx 90GB TSM
>
> Few days ago I noticed processing had ground to halt, after digging
> around I
> have found as soon as server gets busy maybe 4 processes 8 or so
> sessions
> the recovery log begins "sh logpinned" to pin and the Database gets
> locks.
> Shown by running "sh locks"
> And as result the server suffers!
> Now today I have stopped using the new Tech LTO 3 and SATA and
> things are
> coping better but still worse than previous as soon as load is
> increased Log
> pins and processing slows drastically.
>
> Are there any steps I can take which will help my scenario.
> Would a DB UNLOAD RELOAD help that much?
>
> Reference: Recovery log has heaps of room DB has heaps of room 90Gb
> DB with
> 100GB of room.
>
> Any advice is much appreciated.



---

This e-mail may contain confidential and/or privileged information. If
you are not the intended recipient (or have received this e-mail in
error) please notify the sender immediately and delete this e-mail. Any
unauthorized copying, disclosure or distribution of the material in this
e-mail is strictly forbidden.

Please refer to http://www.db.com/en/content/eu_disclosures.htm for
additional EU corporate and regulatory disclosures.


The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain information that is confidential, privileged, and/or otherwise exempt 
from disclosure under applicable law.  If this electronic message is from an 
attorney or someone in the Legal Department, it may also contain confidential 
attorney-client communications which may be privileged and protected from 
disclosure.  If you are not the intended recipient, be advised that you have 
received this message in error and that any use, dissemination, forwarding, 
printing, or copying is strictly prohibited.  Please notify the New York State 
Thruway Authority immediately by either responding to this e-mail or calling 
(518) 436-2700, and destroy all copies of this message and any attachments.