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

["Charly Jones" <charly301@xxxxxxxxxxx>]

>From: "Andy Nolen-Parkhouse" <aparkhouse@attbi.com>
>
> > On Behalf Of Charly Jones
> > Subject: RE: We've Added more memory...but I can't remember!
> >
> > Most systems I have seen recently have lots and lots of > memory and it
>is
> > being mostly wasted.  I can tell because they have an > automatic tuner
>moving
> > memory around like crazy - the faulting is still high - the > bottleneck
>is
> > usually the disk resources (don't get me started on that > topic) - the
>CPU is
> > not being fully utilized - and the solution to any performance > problem
>is to buy more CPU or more memory.
>
>Charly,
>
>If I understand your paragraph above, you are saying that a system with
>a generous amount of memory, an underutilized processor, and a shortage
>of disk arms will experience a high level of faulting.  Can you
>elaborate on this a little (without getting started on the disk arm
>topic too much ;-))?  I don't understand the technical underpinnings
>here.  Or do you think that this in an artifact of the performance tuner
>not directly related to the disk arms?
>
>Regards,
>Andy Nolen-Parkhouse
>

Non-database faulting is bad.  Having not enough disk arms makes it worse.
The tuner can't do anything to organize the work into the right pools, it
can only move memory around and adjust other parameters that aren't going to
help much.  Have you ever wondered why there is a machine pool that you
don't get to put your jobs in?  Because IBM knows that their code will run
better if it doesn't have to contend with your code.  And for that matter,
doesn't have to contend with their own stuff like compilers and queries and
sorts and index builds.  There are some jobs that don't coexist with others
very well - compilers and queries and sorts and index builds come to mind.

Maybe an example will help...


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


"Nothing would please me more than being able to hire ten programmers and
deluge the hobby market with good software."  -  Bill Gates in 1976

"We are still waiting..."  -  Alan Cox in 2002

"Linux is only free if your time is worthless."


Charly Jones
253 265-6244
Gig Harbor
Washington USA



_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx