[Orca-users] Re: FW: Capacity Planning

[Peter Viertel]

I should have added a rider that the 'Add 2G ram at a time' fix is a special
case reserved for when your client is a global investment bank which is
afraid of architectural changes, but has lots of cash. For smaller budgets I
would let the rate slip to about 2000 before  going to the business for an
upgrade, and these days I look for ways to distribute the load to other
servers before building a box up - 'the bigger the box the harder it falls'.

I believe your reasoning is sound for large non-oracle/sybase boxes (e.g. a
filesystem based mail storage server or an nntp thingy) , but I think that
large i/o should not cause unacceptable scanning if the i/o is by a database
engine which is configured to avoid redundant filesystem buffering.

Now that sol8 is finally moving towards general acceptance the red book
becomes dated. Also things have changed again with the serengeti servers. I
imagine our Mr Cockcroft is revising the book around now. (and possibly
looking at upgrading to something more stylish than a red porsche).

-----Original Message-----
From: adrian1978b at yahoo.com [mailto:adrian1978b at yahoo.com]
Sent: 26 April 2001 15:39
To: orca-discuss at yahoogroups.com
Subject: [orca-discuss] Re: FW: Capacity Planning


I don't nessarly agree with this if you have priority paging turned on with
< 2.8 AND the box is doing alot of file system IO. With 2.8 you don't need
priority paging. We have a large 8 proc box that performs significant
amounts of disk IO so there is alot of file system cache, it has a scan rate
of around 300-400. With standard memory thesholds and priority paging a scan
rate of < 4096 means you are only paging out file system cache(solaris
internals page 184). Now a scan rate of 4096 is too high don't get me wrong
but an average scan rate of 1000 or so on such a box is not far fetched.
Once it reaches a 1000 consistantly I'll look into buying more ram. But when
you are sholving gigabytes of data through the CPU consistantly you are
going to be constantly hitting cachefree which will turn your scan rate on
no matter how much ram you put in the box.

Now with smaller boxes such as web servers, etc. I'll still side with the
porsche book that a scan rate of more then 200 means problems, but with
larger boxes you need to start rethinking that number.

Bob

--- In orca-discuss at y..., "Peter Viertel" <peter.viertel at i...> wrote:
> you need more RAM.
>
> A happy system never scans. In the real world you can put up with about
200 scans/s. (per Adrian Cockcroft - Red Porsche book).
>
> So first of all - audit you RAM usage, is the app leaking? or are the
DBA's taking too much shared memory and not leaving enough for the kernel.
>
> If all else fails try more RAM in 2G steps until it goes away.
>
> -----Original Message-----
> From: Edwards, Mark [mailto:MarkE at p...]
> Sent: Thursday, November 09, 2000 00:38
> To: 'orca-discuss at egroups.com'
> Subject: [orca-discuss] FW: Capacity Planning
>
>
>
> > Hi,
> >
> > I have been asked to produce a capaity plan for one of the platforms
that
> > our company runs, however the platform appears to be RAM bound at the
> > moment. (Page Scan rates high and residency times low at times of peak
> > demand). I am also noticing an potential issue with CPU usage. These
> > servers have 6 CPU's on board and 5Gb RAM, however looking at the
> > description you have given of the 'CPU usage' graph - particuarly where
> > you say:
> >
> > "If idle time is always low, check the number of processes in the run
> > queue. More, or faster, CPUs may be necessary. If user CPU time is
> > commonly less than system CPU there may be problems with the system set
> > up."
> >
> > I am noticing a consistent difference between the user and system CPU
> > usage where the user CPU usage indeed appears to be less than the system
> > CPU usage. Might this be additional evidence of a RAM bound state - high
> > amounts of VM swappage going on?
> >
> >  <<o___usr_pct,__sys_pct,__100_-_usr_pct_-_sys_pct-weekly.png>>
> > <<o___scanrate-daily.png>>  <<o___page_rstim-daily.png>>
> >
> > Please forgive me for asking this of you, but I am a tad new to capacity
> > planning and graph interpretation, and looking for some assistance...
> >
> > Mark
> >
> > Mark P. Edwards
> > Pacific Access IT
> > MarkE at p...
> > +61 3 9281 3522
> > +61 407 322 033
> >