ADSM-L

Re: [ADSM-L] TSM 5.4 Performance Issue temporary resolution...

2008-03-19 21:59:54
Subject: Re: [ADSM-L] TSM 5.4 Performance Issue temporary resolution...
From: Dave Canan <ddcanan AT ATTGLOBAL DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 19 Mar 2008 19:00:35 -0700
Matthew,

        You are correct in the use of the memoryefficient diskcachemethod
parameter. This is one way to improve the performance and to help reduce
the impact of APAR IC53531. This is one of the things that was discovered
when we started doing problem diagnostics for this problem.

        You should not have to run a TSM trace that would create a large
trace file to see if this APAR affects you. The TSM instrumentation
parameter (testflag instrument:detail) is a low overhead instrumentation
that creates a small (usually less than 1MB) file. Look at my previous post
to see how to look at the report produced to see if this is impacting your
backup for this Solaris machine.

        Please reply again if you have further questions on this.
At 01:57 PM 3/19/2008 -0400, you wrote:
Regarding, the TSM 5.4 and 5.5 performance issue for UNIX.

From my own debugging and reading on new TSM options for 5.4, I believed it
had to do with the new 'memoryefficient diskcachemethod'
option.

When you set that option, the performance issues for me are resolved using
TSM for Solaris 5.4 and 5.5.

So, give that a try if you can't downgrade to TSM 5.3

      memoryefficient diskcachemethod

Of course, now TSM would use disk space to instead of memory, but it at
least backups are performing better again.
With servers with larger disks,  you have to set, diskcachelocation from
the default, to whatever disk has 2 GB free for every 1 million files.

With Solaris, as long as you have enough free memory and swaps pace, you
can set it to /tmp which is swap + memory..  works out well..

I found it a bit frustrating as I had not had very much luck in getting
them to look further into this issue much since I reported it.
They wanted me to run with the traceflag's that created a 100 GB trace file
that took many days and never finished, I was supposed to upload?

Give me a break, they have to have a lab or something, since the problem is
so easy to repeat.  Come on IBM step up...

Matthew Glanville
www.kodak.com

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

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