RE: We've Added more memory...but I can't remember!

What puzzles me is how to get a handle on the trade-off between memory and
disk arms.  It would help to know from this example how you deduce that
their 16G of memory is "not very well utilized"?

Thanks, John

-----Original Message-----
From: Charly Jones [mailto:charly301@hotmail.com]
Sent: 11 July 2002 15:54
To: midrange-l@midrange.com
Subject: RE: We've Added more memory...but I can't remember!


<snip>

Maybe an example will help...


                           Work with System Status                    OSPREY
                                                            06/27/02
17:14:35
% CPU used . . . . . . . :       23.6    System ASP . . . . . . . :
128.8G
% DB capability  . . . . :       20.3    % system ASP used  . . . : 67.7896
Elapsed time . . . . . . :   00:05:14    Total aux stg  . . . . . :
128.8G
Jobs in system . . . . . :       3664    Current unprotect used . :
14213M
% perm addresses . . . . :       .018    Maximum unprotect  . . . :
46931M
% temp addresses . . . . :       .245

Sys      Pool   Reserved    Max  ----DB-----  --Non-DB---  Act-   Wait- Act-
Pool    Size M   Size M     Act  Fault Pages  Fault Pages  Wait   Inel Inel
  1    2868.61    633.32  +++++     .0    .0     .0    .0  500.1     .0 .0
  2    9915.10       .08     23    5.1  81.1  109.7 174.1  19505     .0 .0
  3    2700.27       .00      5     .0    .0     .0    .0    1.5     .0 .0
  4     900.00       .00      4    3.5  20.6    1.2  17.7   41.3     .0 .0

I'm sorry about the formatting.  This is a screen capture of a five minute
interval from a 12 way system with thousands of users when they were really
busy (you can tell from the active to wait being 19,505 transitions per
minute.)

The question I was asked was: should we buy more memory or CPU?

Welllll, some of the existing CPU is sitting idle, so more processors will
not help.  They have 16 gigabytes of memory that is not very well utilized,
so adding memory (without other changes) will probably provide little
beneficial effect.

The easiest (and least costly) thing they can do to improve performance is
to find a way to reduce the non-database faulting.  The easiest pool to
focus on would be *BASE.  The *BASE pool had 109 faults per second for 5
minutes, or a little over 32,000 faults.  So 32,000 times in that five
minutes something had to be brought into memory from the disks.

With only 17 disk arms and the *BASE pool thrashing like it is, they
probably aren't going to get good performance anytime soon.

--  Charly






 ###  OXFORD INSTRUMENTS   http://www.oxford-instruments.com/  ###

Unless stated above to be non-confidential, this E-mail and any
attachments are private and confidential and are for the addressee
only and may not be used, copied or disclosed save to the addressee.
If you have received this E-mail in error please notify us upon receipt
and delete it from your records. Internet communications are not secure
and Oxford Instruments is not responsible for their abuse by third
parties nor for any alteration or corruption in transmission.