*** Original Author: ADSM-L @ MARIST - ** Remote User **; 08/10/97 09:51am
>Received: from VM.MARIST.EDU by AUDUCADM.DUC.AUBURN.EDU (IBM MVS SMTP V3R1)
> with TCP; Sun, 10 Aug 97 09:51:07 CDT
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (IBM VM SMTP V2R3)
> with BSMTP id 9616; Sun, 10 Aug 97 10:23:53 EDT
>Received: from VM.MARIST.EDU (NJE origin LISTSERV@MARIST) by VM.MARIST.EDU
> (LMail V1.2b/1.8b) with BSMTP id 0124; Sun, 10 Aug 1997 10:23:50 -0400
>Received: from VM.MARIST.EDU by VM.MARIST.EDU (LISTSERV release 1.8c) with NJE
> id 3974 for ADSM-L AT VM.MARIST DOT EDU; Sun, 10 Aug 1997 10:23:48
> -0400
>Received: from MARIST (NJE origin SMTP@MARIST) by VM.MARIST.EDU (LMail
> V1.2b/1.8b) with BSMTP id 0112; Sun, 10 Aug 1997 10:23:48 -0400
>Received: from mailgate.hcc.com by VM.MARIST.EDU (IBM VM SMTP V2R3) with TCP;
> Sun, 10 Aug 97 10:23:47 EDT
>Received: from brw-exc-02.bridgewater.ne.hcc.com
> (brw-exc-02.bridgewater.ne.hcc.com 159.223.84.17 ) by
> mailgate.hcc.com with SMTP (8.7.1/8.7.1) id KAA18968 for
> <ADSM-L AT VM.MARIST DOT EDU>; Sun, 10 Aug 1997 10:23:54 -0400 (EDT)
>Received: by brw-exc-02.bridgewater.ne.hcc.com with SMTP (Microsoft Exchange
> Server Internet Mail Connector Version 4.0.994.63) id
> <01BCA577.83740000 AT brw-exc-02.bridgewater.ne.hcc DOT com>; Sun,
> 10 Aug
> 1997 10:23:58 -0400
>X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63
>Encoding: 105 TEXT
>Message-ID:
> <c=US%a=ATTMAIL%p=HOECHST%[email protected]
> er.ne.hcc.com>
>Date: Sun, 10 Aug 1997 10:23:53 -0400
>Reply-To: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>Sender: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>From: "Pittson, Timothy ,HiServ/NA" <tpittson AT HIMAIL.HCC DOT COM>
>Subject: Re: Reply to ADSM MVS Server Perf
>To: ADSM-L AT VM.MARIST DOT EDU
>
Jerry,
ADSM takes it buffers from above the line.... if you wanted to take
the conservative route you could start out by bumping the bufpoolsize to
8192, monitoring the cache hit ratio, then raising it as necessary. I
believe the minimum recommended cache hit ratio for ADSM is 98% (maybe
one of the IBM folks can verify this). If you're running with the
REGION=40M that's included in the proc supplied with the ADSM code,
you'll probably have to increase that also. We used to run fine with
REGION=96M but I believe the recommended minimum value is now 128M. We
saw a significant improvement in performance when we increased the
bufpoolsize and got our cache hit ratio back in the high 90's so I
suspect you'll see the same kind of improvement.
Good luck !!!
Tim Pittson
tpittson AT himail.hcc DOT com
>----------
>From: Jerry Lawson SMTP:jlawson AT THEHARTFORD DOT COM
>Sent: Friday, August 08, 1997 4:19 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: Reply to ADSM MVS Server Perf
>
>---------------------------- Forwarded with Changes
>---------------------------
>From: INTERNET.OWNERAD at SNADGATE
>Date: 8/8/97 10:08AM
>To: Jerry Lawson at ASUPO
>*To: *ADSM-L at SNADGATE
>Subject: Re: Reply to ADSM MVS Server Perf
>-----------------------------------------------------------------------------
>--
>As I read the manual, the number specified in the bufpool and logpool
>statements is in kilobytes - thus my setting would indicate 1.5MB for the
>pool size (1536) that I specified. Do I read your response to be that you
>recommend a 16MB, or better 32MB pool? I was concerned that the buffer was
>"below the 16M line", but if I am correct, then this is obviously not a
>concern. The manual is of no help - it says that "The maximum value is
>limited only by available virtual memory size."
>
>Jerry Lawson
>jlawson AT thehartford DOT com
>
>______________________________ Forward Header
>__________________________________
>Subject: Re: Reply to ADSM MVS Server Perf
>Author: INTERNET.OWNERAD at SNADGATE
>Date: 8/8/97 10:08 AM
>
>
>Jerry,
> An 86% hit ratio is very low for ADSM... Try bumping up the
>bufpoolsize to a minumum of 16384 or possibly 32768. The logpoolsize
>seems a little low also.. if you do a Q LOG F=D and notice any log pool
>pct. wait, increase this also
>
>>----------
>>From: Jerry Lawson SMTP:jlawson AT THEHARTFORD DOT COM
>>Sent: Friday, August 08, 1997 8:13 AM
>>To: ADSM-L AT VM.MARIST DOT EDU
>>Subject: Reply to ADSM MVS Server Perf
>>
>>---------------------------- Forwarded with Changes
>>---------------------------
>>From: INTERNET.OWNERAD at SNADGATE
>>Date: 8/7/97 3:54PM
>>To: Jerry Lawson at ASUPO
>>*To: *ADSM-L at SNADGATE
>>Subject: Reply to ADSM MVS Server Perf
>>----------------------------------------------------------------------------
>>-
>>--
>>In response to my original posting, Mike Stewart responded:
>>
>><snip - removed original message text - snip>
>>
>>*** Comments From: STEWAJM - Stewart, Mike; 08/07/97 12:54pm
>>
>>You might check your bufpoolsize. If your devices are staying
>>that busy you might be able to speed the process by
>>reducing db activity.
>>
>>My db size is about 5 gb, and expiration processing takes
>>about 30 minutes...that is on a 9672-R3 model, to give you
>>a processor speed reference.
>>
>>Yes, ADSM is a _big_ CPU consumer. Your processor consumption
>>seems comperable to mine (assuming our processor speeds are
>>comperable).
>>
>>** end of response ***
>>
>>I forgot to put processor information in the original note - the
> >system is an Amdahl 5995M 8670 - an 8 engine processor with 60
>>MIP engines.
>>
>>Our Bufferpool is set at 1536K, and our LOGP is set at 256K
>>
>>Bufferpool stats usually shows aaround and 86% buffer cache hit
>>ratio.
>>
>>Jerry Lawson
>>
>
*** Comments From: STEWAJM - Stewart, Mike; 08/11/97 07:22am
An additional note, what you are doing here is trying to
remove IO waits...ADSM isn't burning as much CPU time as it
wants because it is having to wait on db IO.
Although eliminating the db IO will save some CPU time,
I think your net result will be to see ADSM's CPU usage
increase...probably significantly during, say,
expiration processing, where ADSM should be spinning
one of your 8 processors at 100% utilization (but only one
since he will dispatch on only one processor at a time).
|
