ADSM-L

Re: OS390 TSM Performance questions.

2003-02-14 10:11:03
Subject: Re: OS390 TSM Performance questions.
From: Alan Davenport <Alan.Davenport AT SELECTIVE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 14 Feb 2003 10:10:45 -0500
Hi,

 I hoped I made it clear it was pure supposition as to what the number
meant. (: I'm trying to make sense of why, by reducing my region size by
768M performance increased dramatically. My daily maintenance cycle was a
good 3+ hours ahead of schedule when I left for the day yesterday. I'm on
track to see a similar completion time today. Who knows why this is so?
Perhaps noone. My reaction is I am glad that it has helped solve my problem.
At least it has provided a lively discussion!

       Take care,
           Al

-----Original Message-----
From: Bill Kelly [mailto:kellywh AT MAIL.AUBURN DOT EDU]
Sent: Friday, February 14, 2003 8:59 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: OS390 TSM Performance questions.


Hi,

I wanted to clarify, or perhaps retract, something about the 'show memu
SHORT' command that has been mentioned in this thread.  Not surprisingly,
the numbers you get from this command vary depending on what's been going
on in the server.  Specifically, just after startup in a 512 MB region, I
get:

    MAX initial storage  536870912  (512.0 MB)
    Freeheld bytes   69409  (0.1 MB)
    MaxQuickFree bytes 10390159  (9.9 MB)
    83 Page buffers of 12683 : 0 buffers of 1585.
    0 Large buffers of 792 : 1 XLarge buffers of 99.
   61 buffers free: 148 hiAlloc buffers: 87 current buffers.
   12 units of 56 bytes hiAlloc: 12 units of 104 bytes hiCur.

A couple of hours later, after a storage pool copy has run and nightly
backups are in full swing, I get:

    MAX initial storage  536870912  (512.0 MB)
    Freeheld bytes 10397099  (9.9 MB)
    MaxQuickFree bytes 10390159  (9.9 MB)
    83 Page buffers of 12683 : 14 buffers of 1585.
    2 Large buffers of 792 : 18 XLarge buffers of 99.
   21616 buffers free: 48260 hiAlloc buffers: 13604 current buffers.
   13400 units of 104 bytes hiAlloc: 4879 units of 56 bytes hiCur.

Note that the Freeheld number, which intially looked 'bad', now looks
'good'.  As has been pointed out to me off-list, unless you know how to
interpret the numbers, they're just that - a bunch of numbers.  I
should've known better.  :-)

Regards,
Bill

Bill Kelly
Auburn University
kellywh AT mail.auburn DOT edu