ADSM-L

Re: Long, long, long backup sessions

2001-08-24 14:15:04
Subject: Re: Long, long, long backup sessions
From: William Boyer <wboyer AT PTD DOT NET>
Date: Fri, 24 Aug 2001 14:15:13 -0700
Couple other suggestions...

1. Check your no -a settings on the AIX box and your TCPWINDOWSIZE
parameters. sb_max, rfc1323, tcp_sendspace, tcp_recvspace. Also your mbuffs.
Also since you said it is a 100Mb switch, check to make sure that the
adapter is running at 100 full-duplex. There have been issues with the
autosensing.

2. Check your TSM server for database cache hit %.

3. Since it's OS/390, check the performance group/WLM for both TCPIP and
TSM. You also may want to take a little tuning look on the mainframe for the
DASD, especially where the DB and LOG volumes are, paging, ... Also check
the TCPIP buffer settings in the tcp PROFILE parmlib member. Like:


TCPCONFIG        RESTRICTLOWPORTS
                 TCPSENDBFRSIZE     262144
                 TCPRCVBUFRSIZE     262144
                 TCPMAXRCVBUFRSIZE  524288

I also found some problems with the PORT statment:

1500 UDP ADSM     NODELAYACKS  ; ADSM PRODUCTION

The NODELAYACKS really helped performance.

4. Maybe even the lastest PSP bucket for your release of TCPIP. I've had
problems with TCPIP that seriously affected my TSM performance.

5. Try running with the traceflag=instr_client_detail to see exactly where
the most of your time is being spent on the client.

Noticed that your DASD is RAMAC...not very speedy disk. 5MB/sec maybe? Don't
mean to sound critical, we just got off of RAMAC less than a year ago. Went
to a Shark (IBM ESS). Greased Lightning!! Could be some of your bottleneck
could be DASD throughput on the big iron.

Also, just remember this is my $.02 worth and most times it's over priced!
:-)

Bill Boyer
DSS, Inc.

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