ADSM-L

Re: [ADSM-L] Exclude client disk and TSM stgpools in performance testing

2013-11-18 02:45:40
Subject: Re: [ADSM-L] Exclude client disk and TSM stgpools in performance testing
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 18 Nov 2013 08:43:45 +0100
I used ramdisks before for this kind of stuff, TSM doesn't mind it, at
least on AIX it doesn't.
>From my experience TSM is never really bothered by the underlying stuff
when it comes to diskpool writes.
Be sure to tune down TSM v6 memory % before using large ramdisks to not let
the OS run out of memory.



On Thu, Nov 14, 2013 at 12:44 PM, Hans Christian Riksheim <bullhcr AT gmail DOT 
com
> wrote:

> Hi!
>
> When we have performance problems with backups there is always a lot of
> finger pointing. Disk/network/TSM is to blame dependant on which group you
> belong to.
>
> What I would like to do is to use the TSM client-server infrastructure to
> test performance but exclude from the equation any disk bottlenecks on both
> ends.
>
> Like "dsmc sel <virtualfile> size=30G" on the client where virtualfile is
> something the BA client itself generates on the fly. It could be just
> zeroes or maybe even better, something with user defined compressibility if
> we test to a tape drive.
>
> On the TSM server I would like to have a copygroup pointing to /dev/null or
> something similar which we know for certain is not a bottleneck.
>
> I often test ftp with input from /dev/zero out to /dev/null to test the
> network in combination with the OS tcp stack/settings on both client and
> server but that does not test the tunables on the TSM client or the TSM
> server itself.
>
> Maybe a ram disk in both ends.is possible(Is file pool on ramdisk allowed
> by the way?)
>
> Any ideas or if not is this RFE material?
>
> Regards,
>
> Hans Chr.
>

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